Plantilla de datos: Gestión de Incidentes

Bmc Helix
Plantilla de datos: Gestión de Incidentes

Su Plantilla de Datos de Gestión de Incidentes

Esta plantilla proporciona una hoja de ruta clara para recopilar los datos esenciales necesarios para analizar y optimizar su proceso de Gestión de Incidentes en Bmc Helix. Describe los atributos y actividades cruciales a seguir, junto con orientación práctica sobre la extracción de datos. Al seguir esta plantilla, asegurará una base completa y precisa para el descubrimiento de procesos y la mejora.
  • Atributos recomendados para recopilar
  • Actividades clave para el seguimiento
  • Guía de extracción para BMC Helix
¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Atributos de Gestión de Incidentes

Estos son los campos de datos recomendados para incluir en su Registro de eventos para un análisis exhaustivo de su proceso de Gestión de Incidentes.
5 Requerido 7 Recomendado 7 Opcional
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
Requerido Recomendado Opcional

Actividades de Gestión de Incidentes

Estos son los pasos clave del proceso y los hitos a capturar en su Registro de eventos para un descubrimiento y análisis precisos del proceso.
6 Recomendado 8 Opcional
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
Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de BMC Helix