Plantilla de datos: Gestión de Incidentes
Su Plantilla de Datos de Gestión de Incidentes
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de extracción para BMC Helix
Atributos de Gestión de Incidentes
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
ActivityName
|
El nombre de la acción o evento específico que ocurrió en un punto del ciclo de vida del incidente. | ||
|
Descripción
El Nombre de la Actividad describe un paso en el proceso de gestión de incidentes, como 'Incidente Categorizado', 'Asignado al Grupo de Soporte' o 'Incidente Resuelto'. Estas actividades forman los nodos en el mapa de procesos descubierto.\n\nAnalizar la secuencia y frecuencia de estas actividades es fundamental para el Process Mining. Ayuda a descubrir el flujo de proceso real, identificar cuellos de botella entre los pasos, detectar desviaciones del procedimiento operativo estándar y medir la duración de etapas específicas dentro del ciclo de vida del incidente.
Por qué es importante
Este atributo define los pasos en el proceso, permitiendo la visualización del mapa de procesos y el análisis de flujos, cuellos de botella y desviaciones.
Dónde obtener
Normalmente se deriva de cambios de estado, registros de auditoría o registros de eventos específicos asociados con el incidente en la 'HPD:HelpDesk_AuditLogSystem' o tablas de auditoría similares.
Ejemplos
Incidente ReportadoAsignado a Grupo de SoporteInvestigación IniciadaIncidente ResueltoIncidente Cerrado
|
|||
|
Hora de Inicio
EventTimestamp
|
La fecha y hora precisas en que una actividad o evento específico ocurrió para un incidente. | ||
|
Descripción
El timestamp del evento registra el momento en que tuvo lugar cada actividad. Estos datos temporales son críticos para ordenar los eventos cronológicamente y construir el flujo del proceso con precisión.\n\nEn el análisis, los timestamps se utilizan para calcular duraciones entre actividades, medir el tiempo de ciclo total de los incidentes e identificar retrasos o tiempos de espera en el proceso. Comparar los timestamps con los acuerdos de nivel de servicio (SLA) también es esencial para la monitorización del rendimiento y las comprobaciones de cumplimiento.
Por qué es importante
Los timestamps proporcionan el orden cronológico de los eventos y son esenciales para todo análisis basado en el tiempo, incluyendo la medición del rendimiento, la identificación de cuellos de botella y el cumplimiento de SLA.
Dónde obtener
Esta información se encuentra en las tablas de registro de auditoría, como 'HPD:HelpDesk_AuditLogSystem', y corresponde a cada acción registrada o cambio de estado.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
|
|||
|
ID de Incidente
IncidentId
|
El identificador único para cada incidente reportado, que sirve como clave principal para rastrear el ciclo de vida del incidente. | ||
|
Descripción
El ID de Incidente es la piedra angular del análisis de la gestión de incidentes. Identifica de forma única cada caso, permitiendo la agregación de todos los eventos relacionados, cambios de estado y actividades en una única instancia de proceso cohesiva.\n\nEn el Process Mining, este ID vincula cada paso, desde 'Incidente Reportado' hasta 'Incidente Cerrado', permitiendo una vista completa de extremo a extremo del recorrido del incidente. Es esencial para calcular métricas a nivel de caso como el tiempo total de resolución, el número de reasignaciones y la identificación de variantes de proceso.
Por qué es importante
Este atributo es el identificador de caso fundamental, que permite rastrear todo el ciclo de vida de un incidente y analizar su flujo a través del proceso de gestión.
Dónde obtener
Este es un campo principal en el módulo o formulario primario de gestión de incidentes, a menudo etiquetado como 'Incident Number' o 'Incident ID'.
Ejemplos
INC000012345678INC000009876543INC000011223344
|
|||
|
Source System
SourceSystem
|
El sistema del cual se extrajeron los datos del incidente. | ||
|
Descripción
Este atributo identifica el origen de los datos, lo cual es crucial en entornos donde los datos de múltiples sistemas se consolidan para el análisis. Ayuda a asegurar la trazabilidad de los datos y proporciona contexto para la estructura y el contenido de los mismos. Para Bmc Helix, este sería típicamente un valor estático que identifica la instancia o el entorno específico, por ejemplo 'BmcHelix_Production'. Es útil para filtrar y segmentar datos si se integran múltiples sistemas de origen.
Por qué es importante
Aporta trazabilidad y contexto sobre el origen de los datos, lo cual es importante para la gobernanza de datos y la resolución de problemas en entornos con múltiples sistemas.
Dónde obtener
Este es típicamente un valor estático añadido durante el proceso de extracción, transformación y carga de datos (ETL) para identificar la fuente de datos.
Ejemplos
BmcHelixBmcHelix_Prod_EUITSM_Platform_A
|
|||
|
Última actualización de datos
LastDataUpdate
|
El timestamp que indica la última vez que los datos de este registro se actualizaron desde el sistema de origen. | ||
|
Descripción
Este atributo proporciona el timestamp de la extracción de datos más reciente. Es un campo de metadatos esencial para comprender la frescura de los datos analizados. Saber cuándo se actualizaron los datos por última vez ayuda a los analistas y usuarios de negocio a confiar en los conocimientos derivados de la herramienta de process mining. Confirma si el análisis refleja el estado más actual de las operaciones o se basa en datos más antiguos.
Por qué es importante
Garantiza la transparencia sobre la frescura de los datos, lo cual es crítico para tomar decisiones de negocio oportunas y precisas basadas en el análisis de procesos.
Dónde obtener
Este timestamp se genera y se añade durante el proceso de extracción, transformación y carga (ETL) de datos.
Ejemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Agente Asignado
AssignedAgent
|
El agente de soporte individual asignado para manejar el incidente. | ||
|
Descripción
El Agente Asignado es la persona específica responsable del incidente en un momento dado. Esto proporciona un nivel de detalle más granular que el grupo de soporte, permitiendo el análisis del rendimiento individual y la carga de trabajo.\n\nEste atributo es esencial para el dashboard de 'Distribución de Carga de Trabajo del Equipo' y el KPI de 'Volumen de Actividad por Agente Desv. Estándar'. Al analizar el volumen y los tipos de incidentes manejados por cada agente, los gerentes pueden identificar individuos sobrecargados, asegurar una distribución equitativa de la carga de trabajo y detectar oportunidades de capacitación.
Por qué es importante
Permite un análisis granular de la carga de trabajo y el rendimiento individual, ayudando a optimizar la asignación de recursos e identificar a los de mejor rendimiento o a quienes necesitan apoyo.
Dónde obtener
Un campo estándar en el formulario 'HPD:Help Desk', comúnmente denominado 'Assignee'.
Ejemplos
Alice SmithBob JohnsonCharlie Brown
|
|||
|
Categoría de Incidente
IncidentCategory
|
La clasificación del incidente, organizada típicamente en una estructura jerárquica. | ||
|
Descripción
La Categoría de Incidente ofrece una forma estructurada de clasificar incidentes según el servicio, componente o tipo de problema afectado, por ejemplo 'Hardware', 'Software' o 'Red'. Esta categorización es crucial para dirigir los incidentes al equipo correcto y para el análisis posterior de las tendencias de incidentes. El dashboard de 'Precisión de la Categorización de Incidentes' se basa en este atributo, a menudo comparando su valor inicial con su valor al momento de la resolución para medir la calidad del triage inicial. Una categorización precisa ayuda a identificar problemas recurrentes y permite una gestión de problemas más efectiva.
Por qué es importante
Una categorización adecuada es vital para un enrutamiento eficiente, el análisis de tendencias y para evaluar la precisión del diagnóstico inicial.
Dónde obtener
Estos son campos estándar en el formulario 'HPD:Help Desk', a menudo un conjunto de campos en cascada como 'Nivel de Categorización 1', 'Nivel de Categorización 2', etc.
Ejemplos
Software > Enterprise Apps > ERPHardware > Laptop > KeyboardRed > Conectividad > Wi-Fi
|
|||
|
Estado de SLA
SLAStatus
|
Indica si el incidente se encuentra dentro de sus objetivos de acuerdo de nivel de servicio (SLA) o si los ha incumplido. | ||
|
Descripción
El Estado del SLA proporciona un claro indicador del rendimiento del servicio para cada incidente. Típicamente muestra estados como 'Dentro del objetivo', 'Alerta' o 'Incumplido'. Este es a menudo un campo calculado dinámicamente dentro del propio Bmc Helix. Este atributo es esencial para el dashboard de 'Resumen de Incumplimientos de SLA Críticos' y el KPI de 'Tasa de Incumplimiento de SLA para Incidentes Críticos'. Permite la identificación y priorización inmediatas de los incidentes que no cumplen con los compromisos de servicio, facilitando un análisis centrado en las causas de los retrasos.
Por qué es importante
Mide directamente el rendimiento frente a los compromisos y es fundamental para el monitoreo del cumplimiento y la identificación de procesos que causan incumplimientos de SLA.
Dónde obtener
Este es a menudo un campo calculado dentro de Bmc Helix, derivado de la prioridad y antigüedad del incidente. El estado puede almacenarse en un módulo de gestión de SLA relacionado.
Ejemplos
Dentro del ObjetivoAdvertenciaIncumplido
|
|||
|
Estado del Incidente
IncidentStatus
|
El estado actual o histórico del incidente dentro de su ciclo de vida, como 'Nuevo', 'En Curso' o 'Cerrado'. | ||
|
Descripción
El Estado del Incidente indica la etapa de un incidente en un momento dado. A menudo es la fuente para generar el log de 'Actividad', donde un cambio de estado corresponde a un paso del proceso.\n\nAnalizar el estado permite filtrar incidentes por su estado actual, comprender cuánto tiempo se dedica a diferentes estados e identificar incidentes que están 'atascados'. Por ejemplo, un dashboard podría resaltar incidentes que han estado en un estado 'Pendiente' durante un tiempo inusualmente largo.
Por qué es importante
Proporciona una instantánea del progreso de un incidente y es crucial para identificar incidentes estancados y analizar el tiempo invertido en varias etapas.
Dónde obtener
Un campo central en el formulario principal de incidentes, típicamente 'HPD:Help Desk'. El campo a menudo se denomina 'Status'.
Ejemplos
NuevoAsignadoEn ProgresoPendienteResueltoCerrado
|
|||
|
Grupo de Soporte Asignado
AssignedSupportGroup
|
El equipo o grupo de soporte responsable de trabajar en el incidente. | ||
|
Descripción
Este atributo identifica el equipo asignado a un incidente. A medida que un incidente progresa, puede ser reasignado a diferentes grupos de soporte, como la Mesa de Servicio, el Equipo de Redes o el Soporte de Aplicaciones. El seguimiento de los cambios en este atributo es fundamental para el dashboard de 'Análisis de Reasignación de Incidentes'. Permite visualizar los traspasos entre equipos, medir el número de transferencias por incidente e identificar cuellos de botella o lagunas de conocimiento que conducen a reasignaciones excesivas. También apoya el análisis de la distribución de la carga de trabajo entre equipos.
Por qué es importante
Este atributo es clave para analizar el rendimiento del equipo, la distribución de la carga de trabajo y la eficiencia del enrutamiento y los traspasos de incidentes.
Dónde obtener
Un campo estándar en el formulario 'HPD:Help Desk', típicamente denominado 'Assigned Group'.
Ejemplos
Service DeskOperaciones de redAdministración de Bases de datosSoporte de Aplicaciones Nivel 2
|
|||
|
Prioridad
Priority
|
El nivel de prioridad del incidente, que determina la velocidad de resolución requerida. | ||
|
Descripción
La prioridad es un atributo clave que determina la urgencia de un incidente. Suele derivarse del impacto y la urgencia del incidente y se utiliza para asignar recursos y definir los objetivos de los acuerdos de nivel de servicio (SLA). En el análisis de Process Mining, la prioridad se usa para segmentar incidentes y comparar los flujos de proceso de casos de alta prioridad frente a los de baja. Esto ayuda a comprobar si los incidentes críticos realmente se atienden más rápido e identificar cualquier desviación en sus rutas, algo esencial para el dashboard 'High-Priority Incident Performance' y los KPI relacionados.
Por qué es importante
Este atributo es crítico para segmentar el análisis y asegurar que los incidentes de alta urgencia se manejen de acuerdo con los procedimientos y SLAs definidos.
Dónde obtener
Un campo estándar en el formulario 'HPD:Help Desk', típicamente denominado 'Priority'.
Ejemplos
CríticoAltoMedioBajo
|
|||
|
Severidad
Severity
|
La medida del impacto del incidente en el negocio. | ||
|
Descripción
La severidad define cuán significativamente un incidente afecta las operaciones de negocio. Es un factor crítico, junto con la urgencia, para determinar la prioridad del incidente y los SLA asociados.\n\nAnalizar los incidentes por severidad ayuda a comprender el rendimiento del proceso para los problemas más impactantes. Se utiliza en dashboards como el 'Resumen de Incumplimientos de SLA Críticos' para categorizar y enfocarse en los incidentes que representan el mayor riesgo para el negocio.
Por qué es importante
La severidad ayuda a cuantificar el impacto de los incidentes en el negocio, permitiendo un análisis enfocado en mitigar los riesgos operativos más significativos.
Dónde obtener
Consulte la documentación de BMC Helix. Este suele ser un campo estándar en el formulario de incidentes, posiblemente llamado 'Impact' o 'Severity'.
Ejemplos
1-Extenso/Generalizado2-Significativo/Grande3-Moderado/Limitado4-Menor/Localizado
|
|||
|
Channel
Channel
|
El método o canal a través del cual se reportó el incidente. | ||
|
Descripción
El atributo Canal especifica cómo se inició un incidente, por ejemplo, mediante una llamada telefónica, correo electrónico, portal de autoservicio o monitorización automatizada.\n\nAnalizar el proceso por canal puede revelar diferencias importantes en los tiempos de resolución o las rutas del proceso. Por ejemplo, los incidentes reportados a través del portal de autoservicio podrían resolverse más rápido debido a una mejor calidad inicial de los datos. Este análisis puede informar decisiones sobre qué canales promover o mejorar.
Por qué es importante
Ayuda a comprender cómo el método de reporte impacta el ciclo de vida del incidente, revelando oportunidades para optimizar canales específicos para la eficiencia.
Dónde obtener
Un campo estándar en el formulario 'HPD:Help Desk', a menudo denominado 'Reported Source'.
Ejemplos
EmailTeléfonoPortal de autoservicioMonitorización del Sistema
|
|||
|
Código de Resolución
ResolutionCode
|
Un código o categoría que indica cómo se resolvió finalmente el incidente. | ||
|
Descripción
El Código de Resolución captura el resultado final o la naturaleza de la solución aplicada a un incidente. Estos datos estructurados son valiosos para el análisis de causa raíz y para comprender los tipos de soluciones que se requieren con mayor frecuencia.\n\nEn el análisis, este atributo se puede comparar con la 'Categoría de Incidente' inicial para evaluar la precisión de la categorización. También proporciona insights sobre soluciones comunes, ayudando a construir una base de conocimientos o identificar áreas donde se podría aplicar la automatización.
Por qué es importante
Proporciona datos estructurados sobre los resultados de los incidentes, lo que respalda el análisis de causa raíz y la mejora de la gestión del conocimiento y la automatización.
Dónde obtener
Consulte la documentación de BMC Helix. Este campo suele encontrarse en la pestaña o sección de resolución del formulario de incidentes.
Ejemplos
Error de Usuario - Capacitación ProporcionadaParche de Software AplicadoHardware reemplazadoNo se Encontró Fallo
|
|||
|
Duración de la resolución
ResolutionDuration
|
El tiempo total transcurrido desde que un incidente fue reportado por primera vez hasta que fue resuelto. | ||
|
Descripción
Esta métrica mide la duración desde la actividad 'Incidente Reportado' hasta la actividad 'Incidente Resuelto'. Es un indicador clave de rendimiento (KPI) para la eficiencia de todo el proceso de gestión de incidentes.\n\nEste atributo calculado es la base para el KPI 'Tiempo Promedio de Resolución de Incidentes' y el dashboard 'Tiempo de Ciclo de Resolución de Incidentes'. Analizar esta duración en diferentes categorías de incidentes, prioridades o equipos ayuda a identificar fuentes sistémicas de retraso y a medir el impacto de las iniciativas de mejora de procesos.
Por qué es importante
Esta es una medida principal de la eficiencia del proceso y la experiencia del cliente, que refleja directamente el tiempo que lleva restaurar el servicio para los usuarios.
Dónde obtener
Calculado durante la transformación de datos al encontrar la diferencia de tiempo entre el timestamp de la actividad 'Incident Resolved' y la actividad 'Incident Reported' para cada case.
Ejemplos
25920000086400000604800000
|
|||
|
Está Reabierto
IsReopened
|
Un indicador que señala si un incidente ha sido reabierto después de ser resuelto. | ||
|
Descripción
Este atributo calculado es un indicador booleano que es verdadero si un incidente tiene una actividad de 'Incidente Reabierto' en su historial. Una alta tasa de incidentes reabiertos puede señalar problemas con la calidad de las resoluciones o el cierre prematuro de tickets. Este indicador se utiliza directamente en el cálculo del KPI de 'Tasa de Reapertura de Incidentes' y para el dashboard de 'Tendencia de la Tasa de Reapertura de Incidentes'. Permite a los analistas filtrar e investigar fácilmente los incidentes reabiertos para comprender las causas raíz, como soluciones incompletas o falta de comunicación con el usuario.
Por qué es importante
Este indicador mide directamente la calidad de la resolución y la satisfacción del cliente, destacando casos en los que la solución inicial no fue efectiva.
Dónde obtener
Este es un campo calculado, derivado durante la transformación de datos al verificar si el registro de eventos de un incidente contiene una actividad de 'Reopened' o una transición de estado.
Ejemplos
truefalse
|
|||
|
Recuento de Reasignaciones
ReassignmentCount
|
El número total de veces que un incidente fue transferido entre diferentes grupos de soporte. | ||
|
Descripción
Este atributo calculado cuenta cuántas veces cambió el campo 'AssignedSupportGroup' durante el ciclo de vida de un incidente. Un alto número de reasignaciones, a menudo llamado 'ping-pong de tickets', indica ineficiencias en el proceso, como un enrutamiento inicial incorrecto o lagunas de conocimiento dentro de los equipos de soporte. Esta métrica es el núcleo del KPI de 'Reasignaciones Promedio por Incidente' y del dashboard de 'Análisis de Reasignación de Incidentes'. El seguimiento de este recuento ayuda a identificar oportunidades para mejorar las tasas de resolución en la primera llamada y agilizar el proceso de enrutamiento, reduciendo en última instancia el tiempo de resolución.
Por qué es importante
Cuantifica la ineficiencia y la fricción del proceso, destacando los incidentes que pasan de un equipo a otro, lo que retrasa la resolución.
Dónde obtener
Calculado durante la transformación de datos al contar el número de valores distintos o cambios en el campo 'AssignedSupportGroup' a lo largo del ciclo de vida de cada incidente.
Ejemplos
0135
|
|||
|
Servicio de Negocio
BusinessService
|
El servicio de negocio o la aplicación afectada por el incidente. | ||
|
Descripción
Este atributo vincula un incidente a un servicio de negocio específico definido en la Base de Datos de Gestión de Configuración (CMDB), como 'Servicio de Correo Electrónico' o 'Sistema ERP'. Analizar los incidentes por el servicio de negocio afectado es crucial para comprender el impacto en la organización. Ayuda a priorizar los esfuerzos de gestión de problemas en los servicios que generan la mayor cantidad de incidentes o sufren el mayor tiempo de inactividad. Esta visión es esencial para informar sobre el rendimiento de TI desde una perspectiva centrada en el negocio.
Por qué es importante
Conecta los incidentes técnicos con su impacto en el negocio, lo que permite un análisis que prioriza el trabajo según lo que es más crítico para la organización.
Dónde obtener
Este es un campo de Elemento de Configuración (CI) en el formulario de incidentes, que se vincula con la CMDB. El campo podría estar etiquetado como 'Service' o 'CI'.
Ejemplos
Servicio de correo electrónico corporativoSAP ERP FinancialsGestión de Relaciones con Clientes
|
|||
|
SLA Incumplido
IsSlaBreached
|
Un indicador booleano que señala si el tiempo de resolución del incidente superó el objetivo del SLA. | ||
|
Descripción
Esta es una bandera simplificada derivada del atributo 'SLAStatus', donde 'true' indica que el SLA fue incumplido. Esto proporciona un resultado binario claro para facilitar el filtrado y la agregación.\n\nEste atributo se utiliza para calcular el KPI 'Tasa de Incumplimiento de SLA de Incidentes Críticos'. Permite una segmentación sencilla de todos los incidentes en dos grupos, incumplidos y no incumplidos, para analizar las características del proceso que son más comunes entre los incidentes que no cumplen con los objetivos de servicio.
Por qué es importante
Aporta un resultado sencillo y binario sobre el cumplimiento de SLA, lo que facilita calcular las tasas de incumplimiento y analizar las rutas más comunes de los casos no conformes.
Dónde obtener
Derivado del atributo 'SLAStatus' durante la transformación de datos. Si 'SLAStatus' es 'Breached', esta bandera se establece en verdadero.
Ejemplos
truefalse
|
|||
Actividades de Gestión de Incidentes
| Actividad | Descripción | ||
|---|---|---|---|
|
Asignado a Grupo de Soporte
|
Esta actividad significa la asignación inicial del incidente a un grupo de soporte específico para su investigación y resolución. Representa el primer traspaso desde la mesa de servicio a un equipo técnico. | ||
|
Por qué es importante
Este es un hito crítico para el seguimiento de las tasas de resolución al primer contacto y los tiempos de respuesta iniciales. Ayuda a identificar retrasos en la asignación del incidente al equipo correcto.
Dónde obtener
Capturado al rastrear la primera asignación del campo 'Assigned Group' en el historial de auditoría del incidente (HPD:HelpDesk_AuditLogSystem).
Capturar
Inferido del primer cambio registrado en el campo 'Grupo Asignado' en los registros de eventos.
Tipo de evento
inferred
|
|||
|
Incidente Cerrado
|
La actividad final en el ciclo de vida, donde el registro del incidente se cierra formalmente y se convierte en un registro histórico de solo lectura. Esto a menudo ocurre automáticamente después de un período establecido en el estado 'Resuelto'. | ||
|
Por qué es importante
Esta actividad marca el fin definitivo del proceso. El tiempo entre 'Resuelto' y 'Cerrado' puede resaltar retrasos en los procesos administrativos o en las ventanas de confirmación del usuario.
Dónde obtener
Este es un evento distinto inferido de la marca de tiempo (timestamp) cuando el campo 'Status' se actualiza a 'Closed'. Esto se registra en el historial de auditoría.
Capturar
Filtre los registros de auditoría para el cambio de estado a 'Closed'.
Tipo de evento
inferred
|
|||
|
Incidente Reportado
|
Marca la creación de un nuevo registro de incidente en el sistema. Es el punto de partida del ciclo de vida del incidente, normalmente activado por el envío de un usuario a través de un portal, por correo electrónico o por un agente de la mesa de servicio que crea el ticket manualmente. | ||
|
Por qué es importante
Esta actividad es el evento de inicio principal del proceso. Analizar el tiempo desde este evento hasta la resolución es fundamental para medir la duración total del ciclo de vida del incidente e identificar retrasos previos.
Dónde obtener
Este es un evento de creación explícito capturado de la marca de tiempo (timestamp) de 'Submit Date' o 'Reported Date' en el formulario HPD:Help Desk. Es uno de los eventos más confiables y fundamentales del sistema.
Capturar
Capturado del timestamp de creación del registro del incidente en la tabla HPD:Help Desk.
Tipo de evento
explicit
|
|||
|
Incidente Resuelto
|
Indica que se ha implementado una resolución y el servicio se ha restaurado para el usuario. Este es un hito clave, típicamente capturado por un cambio de estado a 'Resuelto'. | ||
|
Por qué es importante
Este es un hito principal para medir el tiempo de resolución principal. Significa el final de la fase de trabajo activa y a menudo inicia el conteo para la confirmación del usuario o los procedimientos de cierre automático.
Dónde obtener
Este es un evento distinto inferido de la marca de tiempo (timestamp) cuando el campo 'Status' se actualiza a 'Resolved'. Este cambio se registra en el historial de auditoría.
Capturar
Filtre los registros de auditoría para el cambio de estado a 'Resolved'.
Tipo de evento
inferred
|
|||
|
Resolución identificada
|
Representa el momento en que un agente de soporte ha encontrado una solución y la ha documentado en el registro del incidente. El incidente ya puede pasar a estado 'Resolved'. | ||
|
Por qué es importante
Este hito marca el final de la fase de investigación técnica. La duración desde este punto hasta el cierre puede revelar cuellos de botella en la comunicación, la verificación y los procesos administrativos.
Dónde obtener
Esto a menudo se infiere de la marca de tiempo (timestamp) cuando se ingresan y guardan los detalles de resolución, justo antes de que el estado cambie a 'Resolved'.
Capturar
Utilice el timestamp de la última modificación antes de que el estado cambie a 'Resuelto'.
Tipo de evento
inferred
|
|||
|
Solución Provisional Implementada
|
Significa que se ha proporcionado una solución temporal al usuario, restaurando la funcionalidad del servicio mientras se desarrolla una solución permanente. Esto a menudo se registra estableciendo un flag o estado específico. | ||
|
Por qué es importante
El seguimiento de esto ayuda a medir la velocidad de restauración del servicio, lo cual es crítico para la satisfacción del usuario. Separa las soluciones temporales de las resoluciones permanentes en el análisis de procesos.
Dónde obtener
Esto se puede inferir del timestamp cuando se completa el campo 'Solución Provisional' en los detalles de resolución del incidente o cuando se utiliza un estado específico de 'Solución Provisional Proporcionada'.
Capturar
Utilice el timestamp de un cambio de estado a un estado de 'Solución provisional' o cuando las notas de resolución que indican una solución provisional se guardan por primera vez.
Tipo de evento
inferred
|
|||
|
Confirmación de Usuario Recibida
|
Representa que la persona usuaria reconoce que la solución proporcionada ha resuelto su problema. A menudo es un paso opcional y puede registrarse mediante una acción en el portal o por un agente. | ||
|
Por qué es importante
Analizar la tasa y la velocidad de las confirmaciones de los usuarios ayuda a evaluar la efectividad de la comunicación y la calidad de la resolución. Una baja tasa de confirmación podría llevar a una mayor tasa de reapertura.
Dónde obtener
Esto es difícil de capturar directamente y puede necesitar ser inferido. Podría ser un estado específico como 'Resolved - Confirmed' o una nota añadida al registro de trabajo del incidente.
Capturar
Requiere un análisis del sistema. Busque entradas en el registro de trabajo o cambios de estado que indiquen comentarios de la persona usuaria.
Tipo de evento
inferred
|
|||
|
Estado Pendiente Reanudado
|
Marca el momento en que se reactiva un incidente que estaba en espera. Sucede cuando se recibe la información requerida y suele reflejarse con el cambio de estado de 'Pending' a 'In Progress'. | ||
|
Por qué es importante
Este evento, junto con 'Incidente en Espera', permite la medición precisa de los tiempos de espera. El análisis de tiempos de espera prolongados puede resaltar problemas de comunicación con usuarios o terceros.
Dónde obtener
Inferido de un cambio de estado de 'Pendiente' a un estado activo como 'En Progreso'. El timestamp está disponible en el registro de eventos.
Capturar
Filtre los registros de auditoría para un cambio de estado de 'Pending' a 'In Progress' o 'Assigned'.
Tipo de evento
inferred
|
|||
|
Incidente Categorizado
|
Representa la clasificación inicial del incidente, que incluye definir su categoría, tipo y elemento. Esta actividad suele realizarla un agente de nivel 1 de la mesa de servicio poco después de reportarse el incidente. | ||
|
Por qué es importante
El seguimiento de esta actividad ayuda a analizar la precisión de las clasificaciones iniciales y su impacto en el enrutamiento y la resolución. Los cambios en la categorización más adelante en el proceso indican retrabajo y posibles brechas de conocimiento.
Dónde obtener
Inferido de la primera vez que los campos de categorización operativa y de producto ('OpCat', 'ProdCat') se rellenan en el registro de eventos del incidente (HPD:HelpDesk_AuditLogSystem).
Capturar
Identificar el primer timestamp en el que se establecen los campos de categorización en el registro de eventos.
Tipo de evento
inferred
|
|||
|
Incidente en Espera
|
Esta actividad ocurre cuando el progreso de un incidente se pausa, típicamente mientras se espera información del usuario o de un proveedor externo. Esto suele reflejarse con un cambio de estado a 'Pendiente'. | ||
|
Por qué es importante
Esta actividad es crucial para calcular con precisión los tiempos de resolución. El tiempo invertido en un estado 'Pendiente' a menudo debe excluirse de los cálculos del SLA para medir de manera justa el rendimiento del equipo de soporte.
Dónde obtener
Inferido de un cambio en el campo 'Estado' a un estado 'Pendiente'. El registro de eventos rastrea el timestamp de este cambio.
Capturar
Filtre los registros de auditoría para cambios de estado a 'Pending' o un estado similar de 'en espera'.
Tipo de evento
inferred
|
|||
|
Incidente Reabierto
|
Ocurre cuando un incidente previamente resuelto o cerrado vuelve a un estado activo. Suele pasar cuando la persona usuaria informa que el problema reapareció. | ||
|
Por qué es importante
Una alta tasa de reapertura indica problemas con la calidad de las resoluciones. El seguimiento de este ciclo de retrabajo es esencial para identificar las causas raíz de las soluciones ineficaces y mejorar la resolución en la primera llamada.
Dónde obtener
Inferido de un cambio de estado de 'Resuelto' o 'Cerrado' de nuevo a un estado activo como 'En Progreso' o 'Asignado'. Esta transición se registra en el historial de auditoría.
Capturar
Filtre los registros de auditoría para un cambio de estado de un estado resuelto/cerrado a un estado abierto.
Tipo de evento
inferred
|
|||
|
Investigación Iniciada
|
Indica que un agente asignado ha comenzado a trabajar activamente en el incidente. Esto a menudo se representa con un cambio de estado de 'Asignado' a 'En Progreso' o un estado similar. | ||
|
Por qué es importante
Medir el tiempo entre la asignación y el inicio de la investigación revela demoras en cola y ayuda a evaluar la capacidad de respuesta del equipo y la carga de trabajo.
Dónde obtener
Esto se infiere de un cambio en el campo 'Status' de 'Assigned' a 'In Progress'. La marca de tiempo (timestamp) de este cambio de estado se registra en el registro de auditoría.
Capturar
Filtre los registros de auditoría para el primer cambio de estado a 'In Progress' después de una asignación.
Tipo de evento
inferred
|
|||
|
SLA Incumplido Detectado
|
Un evento calculado que se produce cuando el tiempo para responder o resolver un incidente supera los objetivos definidos en su Acuerdo de Nivel de Servicio (SLA). No es un evento de sistema directo. | ||
|
Por qué es importante
Identificar los incumplimientos de SLA es crucial para la monitorización del cumplimiento y la priorización de incidentes críticos. Esto ayuda a determinar qué etapas del proceso contribuyen más a dichos incumplimientos.
Dónde obtener
Este evento se calcula comparando el timestamp de la actividad 'Incidente Resuelto' (u otros hitos del SLA) contra la 'Fecha de Reporte' y el objetivo de SLA definido para la prioridad de ese incidente.
Capturar
Derivado al comparar el timestamp de resolución con el timestamp de inicio más la duración del SLA.
Tipo de evento
calculated
|
|||
|
Transferido a Otro Grupo
|
Representa la reasignación de un incidente de un grupo de soporte a otro. Suele ocurrir cuando el grupo inicial no puede resolver el problema y se requiere la experiencia de un equipo diferente. | ||
|
Por qué es importante
Las transferencias frecuentes, o 'ping-ponging', son una fuente importante de retrasos e ineficiencia. El análisis de estas actividades ayuda a identificar problemas de enrutamiento, lagunas de habilidades y cuellos de botella en el proceso.
Dónde obtener
Inferido de un cambio en el valor del campo 'Grupo Asignado' en el historial de auditoría del incidente, posterior a la asignación inicial.
Capturar
Cada cambio en el campo 'Assigned Group' en el registro de auditoría después de la primera asignación representa una transferencia.
Tipo de evento
inferred
|
|||