Su Template de datos para la gestión de incidentes
Su Template de datos para la gestión de incidentes
- Atributos recomendados para recopilar
- Actividades clave que conviene registrar en el proceso
- Guía para extraer datos de su sistema
Atributos de gestión de incidentes
| Nombre | Descripción | ||
|---|---|---|---|
|
ID del incidente
IncidentId
|
Identificador único de cada registro de incidente. | ||
|
Descripción
El ID del incidente es la clave principal de cada incidente y lo identifica de forma única desde su creación hasta su cierre. Vincula todas las actividades, los registros y los cambios relacionados, lo que permite obtener una visión completa del ciclo de vida del incidente, de principio a fin. En Process Mining, este atributo es fundamental porque define el caso. Cada evento que comparte el mismo ID del incidente se considera parte de la misma instancia del proceso, lo que permite reconstruir y analizar cómo se gestiona cada incidente.
Por qué es importante
Este es el identificador esencial del caso, que conecta todos los eventos del ciclo de vida de un incidente y permite analizar el proceso de principio a fin.
Dónde obtenerlo
Es el campo 'Incident Number' (ID de campo: 1000000161) del formulario 'HPD:Help Desk'.
Ejemplos
INC000001234567INC000002345678INC000003456789
|
|||
|
Marca de tiempo del evento
EventTimestamp
|
Fecha y hora exactas en que ocurrió la actividad. | ||
|
Descripción
Esta marca de tiempo registra cuándo ocurrió un evento específico del ciclo de vida del incidente. Proporciona el orden cronológico necesario para reconstruir el flujo del proceso a partir de los datos sin procesar. La marca de tiempo del evento es esencial para todos los análisis basados en el tiempo, como calcular los tiempos de ciclo entre actividades, identificar cuellos de botella en los que los incidentes quedan en espera durante mucho tiempo y medir los tiempos totales de resolución. Es la base temporal del análisis del proceso.
Por qué es importante
Esta marca de tiempo establece el orden cronológico de los eventos, algo fundamental para calcular duraciones, identificar cuellos de botella y comprender la cronología del proceso.
Dónde obtenerlo
El campo 'Last Modified Date' (ID de campo: 6) o campos de fecha específicos del formulario 'HPD:Help Desk'. Para los eventos históricos, se utiliza el campo de marca de tiempo del registro de auditoría.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
Nombre de la actividad
ActivityName
|
Nombre del evento o la tarea específicos que tuvieron lugar durante el ciclo de vida del incidente. | ||
|
Descripción
Este atributo describe la actividad realizada en un momento concreto de un incidente, como 'Incidente notificado', 'Grupo asignado' o 'Incidente resuelto'. Estas actividades son los componentes básicos del mapa del proceso. Analizar la secuencia y la frecuencia de estas actividades permite conocer el flujo real del proceso, identificar las rutas habituales y detectar desviaciones del procedimiento estándar. Es fundamental para comprender qué acciones se llevan a cabo para resolver un incidente.
Por qué es importante
Las actividades definen los pasos del mapa del proceso y permiten visualizar y analizar el flujo de trabajo de gestión de incidentes.
Dónde obtenerlo
Suele obtenerse a partir de los cambios en los campos 'Status' (ID de campo: 7) y 'Status_Reason' del formulario 'HPD:Help Desk', o del formulario 'HPD:Help Desk Audit Log'.
Ejemplos
Incidente notificadoGrupo asignadoResolución implementadaIncidente cerrado
|
|||
|
¿Se incumplió el SLA?
IsSlaBreached
|
Indicador que señala si el incidente se resolvió después de la fecha objetivo del SLA. | ||
|
Descripción
Este atributo booleano es verdadero si el tiempo de resolución del incidente superó el plazo establecido en el SLA. Indica de forma clara y binaria el resultado del rendimiento del SLA para cada incidente. Este indicador es esencial para crear el Dashboard de resumen del rendimiento del SLA de incidentes y calcular el KPI de tasa de cumplimiento del SLA de incidentes. Simplifica el análisis, ya que permite filtrar y agrupar directamente todos los incidentes que no cumplieron sus objetivos de nivel de servicio, lo que facilita investigar las causas de los incumplimientos.
Por qué es importante
Este indicador simplifica el análisis del cumplimiento del SLA: permite filtrar fácilmente todos los incidentes con incumplimientos e investigar sus causas raíz.
Dónde obtenerlo
Se calcula comparando la marca de tiempo del evento 'Incidente resuelto' con 'SlaTargetDate'. Si la marca de tiempo de resolución es posterior a la fecha objetivo, el indicador es verdadero.
Ejemplos
truefalse
|
|||
|
¿Se reabrió?
IsReopened
|
Indicador que señala si un incidente se reabrió después de pasar al estado 'Resuelto'. | ||
|
Descripción
Este atributo booleano es verdadero si el estado de un incidente vuelve a estar activo (por ejemplo, 'En curso') después de que se haya marcado como 'Resuelto'. Esto indica que la solución inicial no fue eficaz o estaba incompleta. Es una medida directa del retrabajo y se utiliza para calcular el KPI de tasa de retrabajo de incidentes. Analizar los incidentes reabiertos ayuda a detectar soluciones de baja calidad, pruebas insuficientes o problemas recurrentes que no se abordaron correctamente. Esta información sirve de base para el Dashboard de rutas de retrabajo y escalamiento.
Por qué es importante
Mide directamente el retrabajo y la calidad de las resoluciones. Una tasa elevada de reapertura apunta a soluciones ineficaces y debilidades en el proceso.
Dónde obtenerlo
Se calcula analizando la secuencia de actividades de un incidente. Si aparece una actividad 'Incidente reabierto' o similar después de 'Solución implementada', el indicador se establece como verdadero.
Ejemplos
truefalse
|
|||
|
Categoría del incidente
IncidentCategory
|
La clasificación del incidente, que suele organizarse en varios niveles. | ||
|
Descripción
La categorización de incidentes permite clasificarlos de forma estructurada, normalmente mediante una jerarquía de varios niveles (por ejemplo, nivel 1: hardware, nivel 2: computadora portátil, nivel 3: batería). Estos datos son esenciales para el enrutamiento, la elaboración de informes y el análisis de tendencias. En Process Mining, la categorización permite analizar por separado los distintos tipos de incidentes. Sirve de base para el Dashboard de precisión de la categorización de incidentes, que compara las categorías iniciales y finales, y ayuda a detectar tendencias para el Dashboard de tendencias de causas raíz.
Por qué es importante
La categorización permite mejorar el enrutamiento, analizar tendencias y comparar el rendimiento de distintos tipos de incidentes.
Dónde obtenerlo
Estos son los campos 'Operational Categorization Tier 1/2/3' del formulario 'HPD:Help Desk'.
Ejemplos
Hardware > Computadora portátil > BateríaSoftware > Aplicación empresarial > Error de inicio de sesiónRed > Conectividad > Wi-Fi
|
|||
|
Estado del incidente
IncidentStatus
|
Estado actual o histórico del incidente en el momento del evento. | ||
|
Descripción
Este atributo indica el estado del incidente, como 'New', 'In Progress', 'Pending', 'Resolved' o 'Closed'. Ofrece una instantánea de la etapa del ciclo de vida en la que se encuentra el incidente. Analizar los cambios de estado es fundamental para comprender el proceso de gestión de incidentes. Se utiliza para definir actividades, medir el tiempo que transcurre en cada estado (por ejemplo, cuánto tiempo permanecen los incidentes en 'Pending') e identificar incidentes que podrían estar atascados o inactivos.
Por qué es importante
Registrar los cambios de estado es fundamental para comprender el avance del incidente y medir cuánto tiempo permanece en estados específicos, como 'Pending' o 'In Progress'.
Dónde obtenerlo
Es el campo 'Status' (ID de campo: 7) del formulario 'HPD:Help Desk'.
Ejemplos
NuevoAsignadoEn cursoPendienteResueltoCerrado
|
|||
|
Grupo asignado
AssignedGroup
|
El grupo de soporte responsable de atender el incidente. | ||
|
Descripción
Este atributo identifica al equipo o departamento asignado al incidente, como 'Mesa de ayuda', 'Equipo de redes' o 'Administradores de bases de datos'. Registrar las asignaciones es clave para comprender cómo fluye el trabajo entre los equipos. Este atributo se utiliza para analizar los traspasos entre equipos, identificar cuellos de botella causados por grupos específicos y medir la tasa de reasignación de incidentes. Permite visualizar el recorrido de un incidente por la organización y detectar áreas con un enrutamiento ineficiente o carencias de conocimiento.
Por qué es importante
Registrar qué grupo tiene asignado el incidente ayuda a analizar los traspasos, detectar ciclos de reasignación e identificar cuellos de botella en equipos específicos.
Dónde obtenerlo
Este es el campo 'Grupo asignado' (ID de campo: 1000000217) del formulario 'HPD:Help Desk'.
Ejemplos
Mesa de ayudaOperaciones de redSoporte de aplicaciones de nivel 2Servicios de infraestructura
|
|||
|
Prioridad
Priority
|
Nivel de prioridad asignado al incidente, que determina la urgencia con la que debe gestionarse. | ||
|
Descripción
La prioridad suele determinarse a partir de la combinación del impacto y la urgencia, y define el orden y la rapidez con que se resuelven los incidentes. Los valores habituales van de 'Crítico' a 'Bajo'. En Process Mining, analizar los incidentes por prioridad es fundamental para evaluar el rendimiento. Permite responder preguntas como «¿Cumplimos los SLA de los incidentes de alta prioridad?» y «¿Los incidentes de baja prioridad sufren demoras más largas?». Filtrar por prioridad permite centrarse en los problemas empresariales más críticos.
Por qué es importante
Este atributo es esencial para segmentar el análisis, agilizar la atención de los incidentes de alta prioridad y cumplir sus objetivos de nivel de servicio específicos.
Dónde obtenerlo
Este es el campo 'Prioridad' (ID de campo: 1000000164) del formulario 'HPD:Help Desk'.
Ejemplos
CríticoAltoMedioBajo
|
|||
|
Responsable asignado
Assignee
|
La persona asignada para atender el incidente. | ||
|
Descripción
El responsable asignado es el agente de soporte o técnico específico que se ocupa del incidente en un momento determinado. Este atributo ofrece un nivel de detalle mayor que el grupo asignado. Analizar el rendimiento por responsable asignado ayuda a identificar a quienes obtienen mejores resultados, a los agentes que podrían necesitar formación adicional y los desequilibrios en la distribución de la carga de trabajo. También permite reconstruir la secuencia exacta de acciones realizadas por las personas que atienden un incidente complejo.
Por qué es importante
Ofrece una visión detallada de la distribución de la carga de trabajo y del rendimiento individual, y ayuda a identificar a quienes obtienen mejores resultados o necesitan apoyo.
Dónde obtenerlo
Este es el campo 'Responsable asignado' (ID de campo: 1000000218) del formulario 'HPD:Help Desk'.
Ejemplos
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Servicio
Service
|
El servicio empresarial o técnico afectado por el incidente. | ||
|
Descripción
Este atributo vincula un incidente con un servicio específico definido en la base de datos de gestión de la configuración (CMDB), como 'Servicio de correo electrónico', 'Acceso VPN' o 'SAP Financials'. Este vínculo es fundamental para comprender el impacto empresarial de los incidentes. Analizarlos por servicio ayuda a identificar los servicios problemáticos que generan muchos incidentes, detectar problemas recurrentes asociados a tecnologías específicas y analizar tendencias para la gestión de problemas.
Por qué es importante
Vincular los incidentes con los servicios empresariales es fundamental para analizar su impacto e identificar qué servicios presentan más problemas.
Dónde obtenerlo
Este es el campo 'ServiceCI' o un campo similar que representa el elemento de configuración (CI) afectado en el formulario 'HPD:Help Desk'.
Ejemplos
Correo electrónico corporativoSAP ERPVPN de acceso remotoPortal de Recursos Humanos
|
|||
|
Canal
Channel
|
El medio utilizado para informar del incidente. | ||
|
Descripción
Este atributo indica cómo se notificó el incidente, por ejemplo, por teléfono, correo electrónico, el portal de autoservicio o en persona. Señala el punto de entrada del incidente en el proceso de soporte. Analizar los incidentes por canal permite descubrir cuáles son más eficaces y cuáles generan incidentes más fáciles o difíciles de resolver. También puede orientar las decisiones sobre dónde invertir en automatización o formación de usuarios; por ejemplo, promoviendo el uso de un portal de autoservicio que recopile mejores datos desde el inicio.
Por qué es importante
Conocer el canal de notificación ayuda a analizar la eficiencia de los distintos métodos de recepción y puede orientar las inversiones en autoservicio o automatización.
Dónde obtenerlo
Este es el campo 'Reported Source' (ID de campo: 1000000215) del formulario 'HPD:Help Desk'.
Ejemplos
Correo electrónicoTeléfonoAutoservicioRegistro directo
|
|||
|
Causa raíz
RootCause
|
El motivo subyacente o la causa última del incidente. | ||
|
Descripción
La causa raíz es el problema fundamental que, si se resuelve, evitaría que el incidente se repitiera. A menudo se identifica durante la investigación de un problema relacionado. Aunque no todos los incidentes tienen una causa raíz documentada, analizar este atributo es fundamental para gestionar los problemas de forma proactiva. Sirve de base para el KPI de tasa de identificación de causas raíz y ayuda a crear Dashboards que muestran tendencias de problemas recurrentes y orientan las iniciativas para implementar soluciones permanentes.
Por qué es importante
Identificar la causa raíz es esencial para gestionar los problemas y reducir el volumen de incidentes recurrentes.
Dónde obtenerlo
Esta información puede estar en un campo específico 'Root Cause' del incidente o, más habitualmente, en un formulario vinculado 'PBI:Problem Investigation'.
Ejemplos
Espacio insuficiente en el disco del servidorError en la configuración de redError de software en la versión 2.1Certificado de seguridad vencido
|
|||
|
Código de cierre
CloseCode
|
El código seleccionado al cerrar un incidente, que indica el resultado de su resolución. | ||
|
Descripción
El código de cierre ofrece un resumen estructurado de cómo se resolvió un incidente. Algunos ejemplos son 'Resuelto por el usuario', 'No se encontró ninguna falla', 'Incidente duplicado' o 'Se aplicó una solución permanente'. Este atributo resulta útil para analizar la eficacia y los resultados de las resoluciones. Ayuda a detectar incidentes cerrados sin una solución real o categorías en las que los usuarios resuelven sus propios problemas con frecuencia, lo que podría indicar oportunidades para mejorar los artículos de la base de conocimientos o las herramientas de autoservicio.
Por qué es importante
Proporciona datos estructurados sobre los resultados de las resoluciones, lo que ayuda a analizar la eficacia de las soluciones y detectar tendencias en el cierre de incidentes.
Dónde obtenerlo
Suele formar parte de la información de resolución o cierre del formulario 'HPD:Help Desk'.
Ejemplos
Resuelto de forma remotaProblema duplicadoError del usuarioNo se requiere ninguna acción
|
|||
|
Descripción de la resolución
Resolution
|
Descripción en texto libre de los pasos realizados para resolver el incidente. | ||
|
Descripción
Este campo contiene un resumen detallado, redactado por una persona, de la resolución final. Explica qué se hizo para solucionar el problema y restablecer el servicio para el usuario. Aunque no está estructurado, este texto puede analizarse con técnicas de minería de texto para identificar patrones de resolución frecuentes, extraer palabras clave relacionadas con problemas específicos o complementar el análisis de causas raíz. Aporta contexto cualitativo que a menudo no está disponible en los campos de datos estructurados.
Por qué es importante
Aporta detalles cualitativos sobre la resolución que pueden analizarse con técnicas de minería de texto para detectar patrones que no se observan en los datos estructurados.
Dónde obtenerlo
Este es el campo 'Resolution' (ID de campo: 1000000156) del formulario 'HPD:Help Desk'.
Ejemplos
Se restableció la contraseña del usuario mediante Active Directory.Se borraron la caché y las cookies del navegador, lo que resolvió el problema de inicio de sesión.Se reinició el conmutador de red del armario IDF 3B.
|
|||
|
Fecha objetivo del SLA
SlaTargetDate
|
La fecha y hora límite para resolver el incidente según su SLA. | ||
|
Descripción
Este atributo almacena la fecha límite para resolver el incidente, según lo establecido en el acuerdo de nivel de servicio (SLA) aplicable. Se calcula en función de la prioridad del incidente y del horario de servicio definido. Esta marca de tiempo sirve como referencia para medir el tiempo real de resolución. Es esencial para calcular el KPI de tasa de cumplimiento del SLA de incidentes y crear Dashboards que muestran el rendimiento del SLA. También permite supervisar de forma proactiva los incidentes que se acercan a la fecha límite.
Por qué es importante
Es la referencia para medir el cumplimiento del SLA. Permite determinar si un incidente se resolvió a tiempo o si se incumplió el acuerdo.
Dónde obtenerlo
Estos datos suelen almacenarse en el formulario 'SLM:Measurement' y vincularse al incidente. No son un campo directo de 'HPD:Help Desk'.
Ejemplos
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
Impacto
Impact
|
La medida del efecto del incidente en los procesos empresariales. | ||
|
Descripción
El impacto mide el alcance de los efectos negativos de un incidente en la empresa. Suele definirse en una escala, por ejemplo: 'Extenso/generalizado', 'Significativo/amplio', 'Moderado/limitado' o 'Menor/localizado'. Junto con la urgencia, el impacto determina la prioridad del incidente. Analizar los incidentes por impacto ayuda a comprender cuáles causan más interrupciones en la actividad empresarial, independientemente de su complejidad técnica. Esto es clave para priorizar las iniciativas de mejora de procesos.
Por qué es importante
Ayuda a cuantificar la gravedad del incidente para la empresa, un factor clave para determinar su prioridad y centrar el análisis en los problemas de mayor impacto.
Dónde obtenerlo
Este es el campo 'Impact' (ID de campo: 1000000163) del formulario 'HPD:Help Desk'.
Ejemplos
1-Extenso/generalizado2-Significativo/amplio3-Moderado/limitado4-Menor/localizado
|
|||
|
Número de reasignaciones
ReassignmentCount
|
El número total de veces que un incidente se asignó a un grupo diferente. | ||
|
Descripción
Esta métrica cuenta cuántas veces cambió el campo 'AssignedGroup' durante el ciclo de vida del incidente. Un valor elevado puede indicar problemas con el enrutamiento inicial, falta de resolución en el primer contacto o problemas complejos que requieren la intervención de varios equipos. Este atributo sirve directamente de base para el KPI de tasa de reasignación de incidentes y el Dashboard de análisis del ciclo de reasignación de incidentes. Ayuda a cuantificar el efecto de «ida y vuelta», en el que los tickets pasan repetidamente de un equipo a otro, lo que provoca retrasos importantes e ineficiencias en el proceso.
Por qué es importante
Cuantifica los problemas de enrutamiento y los traspasos ineficientes, y ayuda a identificar incidentes atrapados en ciclos de reasignación entre equipos.
Dónde obtenerlo
Se calcula contando cuántas veces cambia el valor de 'AssignedGroup' para un ID de incidente determinado en el registro de eventos.
Ejemplos
0135
|
|||
|
Persona que notifica
Submitter
|
La persona que informó inicialmente del incidente. | ||
|
Descripción
La persona que notifica es el usuario final o cliente que experimentó el problema y lo comunicó. No es lo mismo que el responsable asignado, que se ocupa del incidente. Analizar los datos por persona que notifica o por departamento puede ayudar a identificar grupos de usuarios que necesitan más formación o que se ven afectados por un tipo de problema concreto. Así se obtiene una perspectiva centrada en el cliente del proceso de gestión de incidentes.
Por qué es importante
Identifica al usuario que informó del problema y permite analizar los datos por departamento, ubicación o función para detectar tendencias específicas de cada grupo.
Dónde obtenerlo
Esta información se registra en el campo 'Submitter' o en campos relacionados con los datos del cliente del formulario 'HPD:Help Desk'.
Ejemplos
John DoeJane SmithPeter Jones
|
|||
|
Sistema de origen
SourceSystem
|
Sistema del que se extrajeron los datos del incidente. | ||
|
Descripción
Este atributo identifica el origen de los datos, algo especialmente útil en entornos con varias herramientas ITSM o sistemas integrados. Confirma que los datos proceden de la fuente prevista, como una instancia específica de BMC Helix ITSM. En el análisis, ayuda a distinguir procesos o características de los datos que pueden variar entre sistemas de producción, desarrollo o heredados, y garantiza que el linaje de los datos sea claro y fiable.
Por qué es importante
Identifica el origen de los datos, algo fundamental para validarlos y gestionar análisis en varios sistemas integrados.
Dónde obtenerlo
Suele ser un valor estático que se añade durante el proceso de extracción, transformación y carga de datos (ETL).
Ejemplos
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
Última actualización de los datos
LastDataUpdate
|
Marca de tiempo que indica cuándo se actualizaron por última vez en el sistema de origen los datos de este evento. | ||
|
Descripción
Este atributo registra la fecha y hora de la extracción de datos más reciente. Indica la actualidad de los datos analizados, un aspecto importante para saber qué tan recientes son las conclusiones sobre el proceso. Conocer la hora de la última actualización es fundamental para los informes y los Dashboards, ya que permite saber si los datos están actualizados y gestionar las expectativas sobre la inclusión de las actividades más recientes de los incidentes.
Por qué es importante
Indica qué tan actualizados están los datos para que las personas usuarias sepan cuán recientes son el análisis del proceso y las conclusiones obtenidas.
Dónde obtenerlo
Este valor suele generarse y registrarse en el conjunto de datos durante el proceso de extracción de datos (ETL).
Ejemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
Actividades de gestión de incidentes
| Actividad | Descripción | ||
|---|---|---|---|
|
Grupo asignado
|
Esta actividad marca la asignación inicial del incidente a un grupo de soporte específico para su investigación. Se infiere a partir de la primera vez que se completa el campo 'Assigned Group' después de crear el incidente. | ||
|
Por qué es importante
Este es un hito clave que señala el inicio del trabajo activo. Registrar el tiempo hasta la primera asignación es fundamental para evaluar los tiempos de respuesta y la eficiencia de la asignación inicial.
Dónde obtenerlo
Se infiere del registro de auditoría ('HPD:HelpDesk_AuditLogSystem') del formulario 'HPD:Help Desk', que registra la primera vez que se completa el campo 'Assigned Group'.
Capturar
A partir de la marca de tiempo en que se completa por primera vez el campo 'Assigned Group'.
Tipo de evento
inferred
|
|||
|
Incidente cerrado
|
Esta es la actividad final, que marca el cierre formal del registro del incidente una vez confirmada la resolución o transcurrido el periodo de confirmación. Se registra cuando el estado se establece en 'Closed'. | ||
|
Por qué es importante
Este es el evento de fin definitivo del ciclo de vida del incidente. El tiempo entre 'Resolved' y 'Closed' corresponde al periodo de confirmación de la persona usuaria y a las tareas administrativas de cierre.
Dónde obtenerlo
Este evento corresponde a la asignación del valor 'Closed' al campo 'Status' del formulario 'HPD:Help Desk'. La marca de tiempo se registra en el campo 'Closed Date' y en el registro de auditoría.
Capturar
A partir de la marca de tiempo de 'Closed Date' o del cambio de estado a 'Closed'.
Tipo de evento
inferred
|
|||
|
Incidente notificado
|
Esta actividad marca la creación inicial del registro del incidente en el sistema. Se obtiene directamente de la marca de tiempo de creación del incidente en el formulario principal de gestión de incidentes. | ||
|
Por qué es importante
Este es el evento de inicio principal del ciclo de vida del incidente. Es esencial para calcular los tiempos totales de resolución y comprender la frecuencia de llegada de incidentes.
Dónde obtenerlo
Este evento corresponde a la creación del registro en el formulario 'HPD:Help Desk'. La marca de tiempo suele tomarse del campo 'Submit Date' o 'Reported Date'.
Capturar
A partir de la marca de tiempo de 'Submit Date' en el formulario HPD:Help Desk.
Tipo de evento
explicit
|
|||
|
Incidente resuelto
|
Esta actividad marca la resolución oficial del incidente desde la perspectiva de la mesa de ayuda, antes del cierre definitivo. Se registra cuando el estado del incidente se establece en 'Resolved'. | ||
|
Por qué es importante
Este es el hito más importante para medir el cumplimiento de los SLA y el tiempo de resolución. Indica que se ha restablecido el servicio para la persona usuaria.
Dónde obtenerlo
Este evento corresponde a la asignación del valor 'Resolved' al campo 'Status' del formulario 'HPD:Help Desk'. La marca de tiempo se registra en el campo 'Last Resolved Date' y en el registro de auditoría.
Capturar
A partir de la marca de tiempo del cambio de estado a 'Resolved' en el registro de auditoría.
Tipo de evento
inferred
|
|||
|
Investigación iniciada
|
Indica que una persona del equipo de soporte ha empezado a trabajar activamente en el incidente. Suele inferirse a partir del cambio de estado de 'Assigned' a 'In Progress'. | ||
|
Por qué es importante
Este hito marca el paso de la espera en una cola al diagnóstico activo. Analizar el tiempo de espera hasta el inicio de la investigación ayuda a detectar cuellos de botella de recursos y contribuye al Dashboard «Cuellos de botella en el diagnóstico y la investigación».
Dónde obtenerlo
Se infiere de un cambio de estado en el formulario 'HPD:Help Desk'. El evento se activa cuando el campo 'Status' cambia a 'In Progress'; la marca de tiempo se obtiene del registro de auditoría.
Capturar
Se infiere del cambio de estado a 'In Progress' en HPD:HelpDesk_AuditLogSystem.
Tipo de evento
inferred
|
|||
|
A la espera de la confirmación de la persona usuaria
|
Ocurre después de implementar una solución, mientras el equipo de soporte espera que la persona usuaria confirme que funciona. A menudo se representa con el propio estado 'Resolved', que inicia el plazo para el cierre automático. | ||
|
Por qué es importante
Esta actividad es fundamental para el Dashboard «Demoras en la confirmación y verificación de la persona usuaria». Ayuda a cuantificar el tiempo entre la aplicación de una solución y su validación por parte de la persona usuaria, que puede prolongar artificialmente el ciclo de vida del incidente.
Dónde obtenerlo
Este estado comienza cuando el campo 'Status' del formulario 'HPD:Help Desk' cambia a 'Resolved'. La duración se mide desde 'Last Resolved Date' hasta que el incidente pasa a 'Closed' o 'Reopened'.
Capturar
Comienza cuando el estado cambia a 'Resolved' y termina cuando cambia a 'Closed' o 'In Progress'.
Tipo de evento
inferred
|
|||
|
Confirmación recibida de la persona usuaria
|
Representa la confirmación activa de la persona usuaria de que la solución proporcionada resolvió el problema. Puede registrarse como un evento explícito o inferirse de notas o de una acción relacionada en el sistema antes del cierre. | ||
|
Por qué es importante
Registrar esta actividad ofrece una visión más precisa del proceso de validación por parte de la persona usuaria que limitarse a esperar el cierre automático. Ayuda a medir el KPI «Tiempo medio de confirmación de la persona usuaria» y a detectar problemas de comunicación.
Dónde obtenerlo
Puede ser difícil registrarla de forma fiable. Podría inferirse de una entrada en el registro de trabajo o de una actualización específica del motivo del estado justo antes de que el incidente pase a 'Closed'. Puede ser necesario analizar el formulario 'HPD:WorkLog'.
Capturar
Se infiere de entradas específicas del registro de trabajo o de actualizaciones del motivo del estado anteriores al cierre.
Tipo de evento
inferred
|
|||
|
Incidente cancelado
|
Esta actividad representa la finalización de un incidente creado por error o que ya no es pertinente. Se registra cuando el estado del incidente se establece en 'Cancelled'. | ||
|
Por qué es importante
Este es un estado final del incidente, distinto de una resolución satisfactoria. Analizar los incidentes cancelados puede revelar problemas en los canales de creación de incidentes o la existencia de informes duplicados.
Dónde obtenerlo
Se infiere del formulario 'HPD:Help Desk' cuando el campo 'Status' se actualiza a 'Cancelled'. La marca de tiempo se registra en el registro de auditoría.
Capturar
Se infiere del cambio de estado a 'Cancelled' en el registro de auditoría.
Tipo de evento
inferred
|
|||
|
Incidente categorizado
|
Representa el momento en que el incidente se clasifica según las categorías operativas y de producto, y se le asigna una prioridad. Suele inferirse a partir de la incorporación o la última modificación de los campos de categorización. | ||
|
Por qué es importante
Una categorización precisa y oportuna es fundamental para asignar los incidentes de forma eficiente y generar informes. Analizar esta actividad ayuda a detectar demoras o errores en la clasificación inicial y contribuye al Dashboard «Precisión de la categorización de incidentes».
Dónde obtenerlo
Se infiere del registro de auditoría ('HPD:HelpDesk_AuditLogSystem'), que registra los cambios en campos como 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' y 'Priority' del formulario 'HPD:Help Desk'.
Capturar
A partir de la marca de tiempo de la última actualización de los campos de categorización o prioridad después de la creación.
Tipo de evento
inferred
|
|||
|
Incidente reabierto
|
Representa un incidente que se había marcado como resuelto, pero se ha reactivado porque el problema persiste. Se infiere a partir de un cambio de estado de 'Resolved' a un estado activo, como 'In Progress' o 'Assigned'. | ||
|
Por qué es importante
Esta actividad mide directamente el retrabajo y la eficacia de las soluciones iniciales. Un número elevado de incidentes reabiertos es un indicador clave de la baja calidad de las soluciones y contribuye al KPI «Tasa de retrabajo en incidentes».
Dónde obtenerlo
Se infiere del registro de auditoría ('HPD:HelpDesk_AuditLogSystem') al detectar un cambio del campo 'Status' de 'Resolved' a 'In Progress' o 'Assigned' para un ID de incidente determinado.
Capturar
Se infiere de la transición de estado de 'Resolved' a un estado activo.
Tipo de evento
inferred
|
|||
|
Incumplimiento de SLA
|
Este evento calculado ocurre cuando el tiempo de resolución de un incidente supera el objetivo definido en el acuerdo de nivel de servicio. Se obtiene al comparar la marca de tiempo de resolución con la fecha límite del SLA. | ||
|
Por qué es importante
Esta actividad es fundamental para el Dashboard «Resumen del rendimiento del SLA de incidentes» y el KPI «Tasa de cumplimiento de los SLA de incidentes». Señala directamente los incidentes que no cumplieron los compromisos de servicio.
Dónde obtenerlo
Se calcula comparando 'Last Resolved Date' con 'Target Date' (fecha límite del SLA) en el formulario 'HPD:Help Desk'. Si el incidente aún no se ha resuelto, el cálculo puede hacerse con la hora actual.
Capturar
Evento calculado: ocurre si 'Last Resolved Date' > 'Target Date'.
Tipo de evento
calculated
|
|||
|
Pendiente de información del cliente
|
Representa el momento en que el avance del incidente se detiene mientras se espera información o una acción de la persona usuaria. Se infiere a partir de un cambio de estado a 'Pending'. | ||
|
Por qué es importante
Esta actividad permite distinguir el tiempo de trabajo del equipo de soporte del tiempo de espera del cliente. Analizar cuánto tiempo permanece el incidente en este estado es fundamental para comprender cómo afectan las demoras en las respuestas de las personas usuarias al tiempo total de resolución.
Dónde obtenerlo
Se infiere del formulario 'HPD:Help Desk' cuando el campo 'Status' se actualiza a 'Pending'. El motivo específico suele encontrarse en el campo 'Status_Reason'.
Capturar
Se infiere del cambio de estado a 'Pending' en HPD:HelpDesk_AuditLogSystem.
Tipo de evento
inferred
|
|||
|
Resolución implementada
|
Esta actividad indica que el equipo de soporte ha aplicado una solución o una alternativa provisional. Suele inferirse cuando el estado del incidente cambia a 'Resolved'. | ||
|
Por qué es importante
Este es un hito fundamental que indica que se ha proporcionado una solución. Es un dato clave para medir el tiempo que se tarda en aplicar una solución una vez finalizada la investigación.
Dónde obtenerlo
Suele inferirse cuando el campo 'Status' del formulario 'HPD:Help Desk' cambia a 'Resolved'. La marca de tiempo se registra en el campo 'Last Resolved Date' y en el registro de auditoría.
Capturar
A partir de la marca de tiempo de 'Last Resolved Date' o del cambio de estado a 'Resolved'.
Tipo de evento
inferred
|
|||
|
Transferido a otro grupo
|
Esta actividad ocurre cuando se reasigna un incidente de un grupo de soporte a otro. Se infiere al detectar un cambio en el campo 'Assigned Group' después de la asignación inicial. | ||
|
Por qué es importante
Las transferencias frecuentes indican una asignación inicial incorrecta o falta de conocimientos. Registrar esta actividad es esencial para el Dashboard «Análisis del ciclo de reasignación de incidentes» y el KPI «Tasa de reasignación de incidentes».
Dónde obtenerlo
Se infiere del registro de auditoría ('HPD:HelpDesk_AuditLogSystem') al identificar cambios posteriores en el campo 'Assigned Group' del formulario 'HPD:Help Desk', después de que se haya completado por primera vez.
Capturar
Identifique los cambios en el campo 'Assigned Group' posteriores a la asignación inicial.
Tipo de evento
inferred
|
|||
Guías de extracción
¿Listo para empezar?
Utilice este Template para poner en marcha sus iniciativas de Process Mining y descubrir información valiosa en los datos de gestión de incidentes. Empiece hoy mismo a optimizar sus operaciones.
¡Resuelva hoy los incidentes recurrentes en BMC Helix ITSM!
Reduzca el MTTR un 35 % y elimine los incumplimientos de SLA para aumentar la satisfacción de los usuarios.
No se requiere tarjeta de crédito. Prueba gratuita de 14 días.