Plantilla de Datos: Gestión de Incidencias
Su Plantilla de Datos para la Gestión de Incidentes
- Atributos recomendados para recopilar
- Actividades clave para rastrear en su proceso
- Guía de extracción para su sistema de datos
Atributos de Gestión de Incidentes
| Nombre | Descripción | ||
|---|---|---|---|
|
ID de Incidente
IncidentId
|
El identificador único para cada registro de incidente. | ||
|
Descripción
El Incident ID sirve como la clave principal para cada incidente, identificándolo de forma única desde su creación hasta su cierre. Vincula todas las actividades, los registros y los cambios relacionados, permitiendo una vista completa y de extremo a extremo del ciclo de vida del incidente. En Process Mining, este atributo es fundamental, ya que define el caso. Cada evento con el mismo Incident ID se considera parte de la misma instancia de proceso, permitiendo la reconstrucción y el análisis de cómo se gestionan los incidentes individuales.
Por qué es importante
Este es el identificador esencial del caso que conecta todos los eventos en el ciclo de vida de un incidente, lo que posibilita un análisis de procesos de principio a fin.
Dónde obtener
Este es el campo 'Incident Number' (Field ID: 1000000161) en el formulario 'HPD:Help Desk'.
Ejemplos
INC000001234567INC000002345678INC000003456789
|
|||
|
Nombre de la Actividad
ActivityName
|
El nombre del evento o tarea específica que ocurrió dentro del ciclo de vida del incidente. | ||
|
Descripción
Este atributo describe la actividad que se realizó en un momento específico para un incidente, como 'Incidente Reportado', 'Grupo Asignado' o 'Incidente Resuelto'. Estas actividades son los bloques de construcción del mapa de procesos. Analizar la secuencia y frecuencia de estas actividades revela el flujo de proceso real, identifica rutas comunes y resalta las desviaciones del procedimiento estándar. Es crucial para comprender qué acciones se toman para resolver un incidente.
Por qué es importante
Las actividades definen los pasos en el mapa de procesos, permitiendo la visualización y el análisis del workflow de gestión de incidentes.
Dónde obtener
Normalmente se deriva de cambios en los campos 'Status' (ID de Campo: 7) y 'Status_Reason' en el formulario 'HPD:Help Desk', o del formulario 'HPD:Help Desk Audit Log'.
Ejemplos
Incidente ReportadoGrupo AsignadoResolución ImplementadaIncidente Cerrado
|
|||
|
Timestamp del Evento
EventTimestamp
|
La fecha y hora exactas en que ocurrió la actividad. | ||
|
Descripción
Esta marca de tiempo registra cuándo ocurrió un evento específico en el ciclo de vida del incidente. Proporciona el orden cronológico necesario para reconstruir el flujo del proceso a partir de datos brutos. La Marca de Tiempo del Evento es esencial para todo análisis basado en el tiempo, lo que incluye el cálculo de los tiempos de ciclo entre actividades, la identificación de cuellos de botella donde los incidentes esperan durante largos períodos, y la medición de los tiempos de resolución generales. Es la columna vertebral temporal del análisis de procesos.
Por qué es importante
Esta marca de tiempo proporciona el orden cronológico de los eventos, lo cual es fundamental para calcular duraciones, identificar cuellos de botella y comprender la línea de tiempo del proceso.
Dónde obtener
La 'Last Modified Date' (ID de Campo: 6) o campos de fecha específicos del formulario 'HPD:Help Desk'. Para eventos históricos, esto se obtiene del campo timestamp del audit log.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
Asignado
Assignee
|
El usuario individual asignado para trabajar en el incidente. | ||
|
Descripción
El Assignee es el agente de soporte o técnico específico responsable del incidente en un momento dado. Esto proporciona un nivel de detalle más granular que el Assigned Group. Analizar el rendimiento por assignee puede ayudar a identificar a los agentes con mejor desempeño, a los que puedan necesitar formación adicional y los desequilibrios en la distribución de la carga de trabajo. También se utiliza para rastrear la secuencia exacta de acciones tomadas por las personas que trabajan en un incidente complejo.
Por qué es importante
Ofrece una vista granular de la distribución de la carga de trabajo y el rendimiento individual, ayudando a identificar a los empleados con mejor rendimiento o a los agentes que necesitan apoyo.
Dónde obtener
Este es el campo 'Assignee' (Field ID: 1000000218) en el formulario 'HPD:Help Desk'.
Ejemplos
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Categoría de Incidente
IncidentCategory
|
La clasificación del incidente, a menudo en una estructura por niveles. | ||
|
Descripción
La categorización de incidentes ofrece una forma estructurada de clasificar los incidentes, utilizando típicamente una jerarquía multinivel (por ejemplo, Nivel 1: Hardware, Nivel 2: Laptop, Nivel 3: Batería). Estos datos son esenciales para el enrutamiento, la generación de informes y el análisis de tendencias. En process mining, la categorización se utiliza para analizar diferentes tipos de incidentes por separado. Sirve de apoyo al dashboard de Precisión de la Categorización de Incidentes al comparar las categorías iniciales y finales, y ayuda a identificar tendencias para el dashboard de Tendencias de Causa Raíz.
Por qué es importante
La categorización permite un enrutamiento preciso, un análisis de tendencias y una comparación de rendimiento entre diferentes tipos de incidentes.
Dónde obtener
Estos son los campos 'Operational Categorization Tier 1/2/3' en el formulario 'HPD:Help Desk'.
Ejemplos
Hardware > Portátil > BateríaSoftware > Aplicación Empresarial > Error de Inicio de SesiónRed > Conectividad > Wi-Fi
|
|||
|
Es Reabierto
IsReopened
|
Un indicador que muestra si una incidencia fue reabierta después de haber sido puesta en estado 'Resuelto'. | ||
|
Descripción
Este atributo booleano es verdadero si el estado de un incidente volvió a un estado activo (como 'In Progress') después de haber sido marcado como 'Resolved'. Esto indica que la solución inicial no fue efectiva o completa. Esta 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 identificar soluciones de baja calidad, pruebas insuficientes o problemas recurrentes que no fueron abordados correctamente, apoyando el dashboard de Rutas de Retrabajo y Escalada.
Por qué es importante
Mide directamente la reelaboración y la calidad de las resoluciones. Una alta tasa de reapertura indica soluciones ineficaces y debilidades en el proceso.
Dónde obtener
Calculado analizando la secuencia de actividades para un incidente. Si una actividad de 'Incidente Reabierto' o similar aparece después de una actividad de 'Resolución Implementada', este indicador se establece en verdadero.
Ejemplos
truefalse
|
|||
|
Estado del Incidente
IncidentStatus
|
El 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'. Proporciona una instantánea de dónde se encuentra el incidente en su ciclo de vida. Analizar los cambios de estado es fundamental para comprender el proceso de gestión de incidentes. Se utiliza para definir actividades, medir el tiempo invertido en diferentes estados (por ejemplo, cuánto tiempo los incidentes están 'Pending') e identificar incidentes que podrían estar atascados o inactivos.
Por qué es importante
El seguimiento de los cambios de estado es fundamental para comprender el progreso del incidente y medir cuánto tiempo permanece en estados específicos como 'Pending' o 'In Progress'.
Dónde obtener
Este es el campo 'Status' (Field ID: 7) en el formulario 'HPD:Help Desk'.
Ejemplos
NuevoAsignadoEn ProgresoPendienteResueltoCerrado
|
|||
|
Grupo Asignado
AssignedGroup
|
El grupo de soporte responsable de trabajar en el incidente. | ||
|
Descripción
Este atributo identifica al equipo o departamento asignado al incidente, como 'Service Desk', 'Network Team' o 'Database Administrators'. El seguimiento de las asignaciones es clave para comprender el flujo de trabajo entre equipos. Este atributo se utiliza para analizar las transferencias entre equipos, identificar cuellos de botella causados por grupos específicos y medir la Tasa de Reasignación de Incidentes. Ayuda a visualizar el recorrido que sigue un incidente a través de la organización y destaca las áreas con rutas ineficientes o lagunas de conocimiento.
Por qué es importante
El seguimiento del grupo asignado ayuda a analizar las transferencias, identificar bucles de reasignación y detectar cuellos de botella dentro de equipos específicos.
Dónde obtener
Este es el campo 'Assigned Group' (Field ID: 1000000217) en el formulario 'HPD:Help Desk'.
Ejemplos
Service DeskOperaciones de RedSoporte de Aplicaciones Nivel 2Servicios de Infraestructura
|
|||
|
Prioridad
Priority
|
El nivel de prioridad asignado al incidente, determinando su urgencia de gestión. | ||
|
Descripción
La prioridad se deriva típicamente de la combinación de impacto y urgencia, y dicta el orden y la velocidad de resolución de incidentes. Los valores comunes van de 'Crítico' a 'Bajo'. En Process Mining, analizar los incidentes por prioridad es crucial para el análisis del rendimiento. Ayuda a responder preguntas como: '¿Estamos cumpliendo los SLA para incidentes de alta prioridad?' y '¿Los incidentes de baja prioridad experimentan retrasos más largos?'. Filtrar por prioridad permite un análisis enfocado en los problemas de negocio más críticos.
Por qué es importante
Este atributo es esencial para segmentar el análisis y garantizar que los incidentes de alta prioridad se gestionen más rápidamente y cumplan sus objetivos de nivel de servicio específicos.
Dónde obtener
Este es el campo 'Priority' (Field ID: 1000000164) en el formulario 'HPD:Help Desk'.
Ejemplos
CríticoAltoMedioBajo
|
|||
|
Servicio
Service
|
El servicio de negocio o técnico afectado por el incidente. | ||
|
Descripción
Este atributo vincula un incidente a un servicio específico definido en la Configuration Management Database (CMDB), como 'Email Service', 'VPN Access' o 'SAP Financials'. Esta vinculación es crítica para comprender el impacto comercial de los incidentes. Analizar los incidentes por servicio ayuda a identificar servicios problemáticos que generan un alto volumen de incidentes, destaca problemas recurrentes vinculados a tecnologías específicas y apoya el análisis de tendencias para la gestión de problemas.
Por qué es importante
Conectar los incidentes a los servicios empresariales es crucial para el análisis de impacto y para identificar qué servicios son más propensos a problemas.
Dónde obtener
Este es el campo 'ServiceCI' o un campo similar que representa el Configuration Item (CI) afectado en el formulario 'HPD:Help Desk'.
Ejemplos
Correo Electrónico CorporativoSAP ERPVPN de Acceso RemotoPortal de Recursos Humanos
|
|||
|
SLA Incumplido
IsSlaBreached
|
Un indicador que muestra si la incidencia se resolvió después de su fecha objetivo de SLA. | ||
|
Descripción
Este atributo booleano es verdadero si el tiempo de resolución del incidente superó su SLA definido. Proporciona un resultado claro y binario para el rendimiento del SLA en cada incidente. Esta bandera es esencial para crear el dashboard de 'Visión General del Rendimiento del SLA de Incidentes' y calcular el KPI de 'Tasa de Cumplimiento de SLA de Incidentes'. Simplifica el análisis al permitir el filtrado y la agregación directos de todos los incidentes que no lograron cumplir sus objetivos de nivel de servicio, facilitando la investigación de las razones de los incumplimientos.
Por qué es importante
Esta bandera simplifica el análisis de cumplimiento del SLA, facilitando el filtrado de todos los incidentes incumplidos y la investigación de las causas raíz.
Dónde obtener
Calculado comparando el timestamp del evento 'Incidente Resuelto' con el SlaTargetDate. Si el timestamp de resolución es posterior a la fecha objetivo, este indicador es verdadero.
Ejemplos
truefalse
|
|||
|
Tiempo de Resolución de Incidente
IncidentResolutionTime
|
El tiempo total transcurrido desde que se reportó un incidente por primera vez hasta que se resolvió. | ||
|
Descripción
Esta es una métrica calculada que representa la duración entre las actividades 'Incident Reported' e 'Incident Resolved'. Es uno de los KPIs más comunes e importantes en la gestión de incidentes. Esta métrica mide directamente la eficiencia del proceso de resolución. En Process Mining, se utiliza como un indicador de rendimiento principal, analizado en diferentes categorías de incidentes, prioridades y equipos para identificar áreas de mejora y rastrear el impacto de los cambios en el proceso a lo largo del tiempo.
Por qué es importante
Este es un KPI crítico que mide la eficiencia de principio a fin del proceso de gestión de incidentes, impactando directamente en la satisfacción del usuario.
Dónde obtener
Calculado restando el timestamp del primer evento del timestamp del evento 'Incidente Resuelto' para cada ID de incidente.
Ejemplos
2592003600864000
|
|||
|
Causa Raíz
RootCause
|
La razón subyacente o la causa última del incidente. | ||
|
Descripción
La Causa Raíz es el problema fundamental que, si se abordara, evitaría que el incidente se repitiera. Esto a menudo se identifica como parte de un proceso relacionado de investigación de problemas. Aunque no todos los incidentes tendrán una Causa Raíz documentada, analizar este atributo es crítico para una gestión proactiva de problemas. Apoya el KPI de 'Tasa de Identificación de Causa Raíz' y ayuda a crear dashboards que rastrean tendencias en problemas recurrentes, guiando los esfuerzos para implementar soluciones permanentes.
Por qué es importante
Identificar la causa raíz es esencial para la gestión de problemas y para los análisis orientados a reducir el volumen de incidentes recurrentes.
Dónde obtener
Esta información podría estar en un campo 'Root Cause' dedicado en el incidente o, más comúnmente, en un formulario vinculado de 'PBI:Problem Investigation'.
Ejemplos
Espacio en disco insuficiente en el servidorError de configuración de redBug de software en la versión 2.1Certificado de seguridad caducado
|
|||
|
Channel
Channel
|
El método utilizado para reportar el incidente. | ||
|
Descripción
Este atributo especifica cómo se envió el incidente, por ejemplo, mediante llamada telefónica, correo electrónico, portal de self-service o atención presencial directa. Indica el punto de entrada del incidente en el proceso de soporte. Analizar los incidentes por canal puede revelar qué canales son más efectivos o cuáles generan incidentes más fáciles o difíciles de resolver. También puede informar decisiones sobre dónde invertir en automatización o capacitación de usuarios, por ejemplo, promoviendo el uso de un portal de self-service que capture mejores datos iniciales.
Por qué es importante
Comprender el canal de envío ayuda a analizar la eficiencia de los diferentes canales de ingreso y puede orientar las inversiones en self-service o automatización.
Dónde obtener
Este es el campo 'Reported Source' (Field ID: 1000000215) en el formulario 'HPD:Help Desk'.
Ejemplos
EmailTeléfonoSelf ServiceEntrada Directa
|
|||
|
Código de Cierre
CloseCode
|
El código seleccionado al cerrar un incidente, indicando el resultado de la resolución. | ||
|
Descripción
El Close Code proporciona un resumen estructurado de cómo se resolvió un incidente. Los ejemplos incluyen 'Resuelto por el Usuario', 'No se encontró fallo', 'Incidente Duplicado' o 'Solución Permanente Aplicada'. Este atributo es valioso para analizar la eficacia y los resultados de la resolución. Puede ayudar a identificar incidentes que se cerraron sin una solución real o resaltar categorías donde 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 self-service.
Por qué es importante
Proporciona datos estructurados sobre los resultados de la resolución, ayudando a analizar la efectividad de las soluciones y a identificar tendencias en cómo se cierran los incidentes.
Dónde obtener
Esto suele formar parte de la información de resolución o cierre en el formulario 'HPD:Help Desk'.
Ejemplos
Resuelto RemotamenteIncidencia DuplicadaError del UsuarioNo se Requiere Acción
|
|||
|
Conteo de Reasignaciones
ReassignmentCount
|
El número total de veces que un incidente fue reasignado a un grupo diferente. | ||
|
Descripción
Esta métrica cuenta cuántas veces se modificó el campo AssignedGroup durante el ciclo de vida del incidente. Un número elevado sugiere problemas con el enrutamiento inicial, falta de resolución en el primer contacto o problemas complejos que requieren la intervención de múltiples equipos. Este atributo respalda directamente 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 'ping-pong' en el que los tickets se pasan de un equipo a otro, lo que provoca retrasos significativos e ineficiencia en el proceso.
Por qué es importante
Cuantifica el enrutamiento y las transferencias ineficientes, ayudando a identificar incidentes que quedan atascados en bucles de reasignación entre equipos.
Dónde obtener
Calculado contando el número de veces que el valor de 'AssignedGroup' cambia para un ID de incidente dado en el registro de eventos.
Ejemplos
0135
|
|||
|
Descripción de la Resolución
Resolution
|
Una descripción en texto libre de los pasos tomados para resolver la incidencia. | ||
|
Descripción
Este campo contiene el resumen detallado y redactado por humanos de la resolución final. Explica qué se hizo para solucionar el problema y restaurar el servicio al usuario. Aunque no estructurados, estos datos de texto pueden analizarse utilizando técnicas de text mining para identificar patrones comunes de resolución, extraer palabras clave relacionadas con problemas específicos o complementar el análisis de la causa raíz. Proporciona un contexto cualitativo que a menudo carecen los campos de datos estructurados.
Por qué es importante
Ofrece detalles cualitativos sobre la resolución, que pueden usarse en el text mining para encontrar patrones no visibles en datos estructurados.
Dónde obtener
Este es el campo 'Resolution' (Field ID: 1000000156) en el formulario 'HPD:Help Desk'.
Ejemplos
La contraseña del usuario fue restablecida a través de Active Directory.Se borró el caché y las cookies en el navegador, lo que resolvió el problema de login.Se reinició el switch de red en el armario IDF 3B.
|
|||
|
Fecha Objetivo de SLA
SlaTargetDate
|
La fecha y hora en que se espera que se resuelva el incidente según su SLA. | ||
|
Descripción
Este atributo almacena la fecha límite para la resolución de incidentes, según lo definido por el Service Level Agreement (SLA) aplicable. Se calcula en función de la prioridad del incidente y las horas de servicio definidas. Este timestamp es la referencia con la que se mide el tiempo real de resolución. Es esencial para calcular el KPI de 'Tasa de Cumplimiento de SLA de Incidentes' y para construir dashboards que visualicen el rendimiento del SLA. Permite un monitoreo proactivo de los incidentes que se acercan a su fecha límite.
Por qué es importante
Esta es la referencia para medir el cumplimiento del SLA. Permite el cálculo de si un incidente se resolvió a tiempo o incumplió su acuerdo.
Dónde obtener
Estos datos normalmente se almacenan en el formulario 'SLM:Measurement' y están vinculados al incidente. No es un campo directo en '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 de negocio. | ||
|
Descripción
El impacto evalúa la magnitud del efecto adverso de un incidente en el negocio. Frecuentemente se define en una escala, como 'Extenso/Generalizado', 'Significativo/Grande', 'Moderado/Limitado' o 'Menor/Localizado'. Combinado con la Urgencia, el impacto determina la Prioridad del incidente. Analizar por impacto ayuda a comprender qué incidentes causan la mayor interrupción del negocio, independientemente de su complejidad técnica. Esto es clave para priorizar los esfuerzos de mejora del proceso.
Por qué es importante
Ayuda a cuantificar la gravedad empresarial de una incidencia, lo cual es un componente clave para determinar la prioridad y centrar el análisis en los problemas de alto impacto.
Dónde obtener
Este es el campo 'Impact' (Field ID: 1000000163) en el formulario 'HPD:Help Desk'.
Ejemplos
1-Extenso/Generalizado2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
Remitente
Submitter
|
La persona que reportó inicialmente el incidente. | ||
|
Descripción
El Submitter es el usuario final o cliente que experimentó el problema y lo reportó. Esto es distinto del assignee, quien trabaja en el incidente. Analizar los datos por submitter o su departamento puede ayudar a identificar grupos de usuarios específicos que puedan requerir más formación o grupos que se ven afectados por un tipo particular de problema. Proporciona una visión centrada en el cliente del proceso de gestión de incidentes.
Por qué es importante
Identifica al usuario que reportó el problema, lo que permite realizar análisis basados en el departamento, la ubicación o el rol del usuario para encontrar tendencias específicas.
Dónde obtener
Esta información se captura en el campo 'Submitter' o en campos relacionados con la información del cliente en el formulario 'HPD:Help Desk'.
Ejemplos
John DoeJane SmithPeter Jones
|
|||
|
Source System
SourceSystem
|
El sistema del que se extrajeron los datos del incidente. | ||
|
Descripción
Este atributo identifica el origen de los datos, lo cual es especialmente útil en entornos con múltiples herramientas ITSM o sistemas integrados. Confirma que los datos provienen de la fuente esperada, como una instancia específica de BMC Helix ITSM. En el análisis, ayuda a diferenciar procesos o características de datos que podrían variar entre sistemas de producción, desarrollo o legados, asegurando que la trazabilidad de los datos sea clara y confiable.
Por qué es importante
Identifica el origen de los datos, lo cual es crucial para la validación de datos y para gestionar análisis en múltiples sistemas integrados.
Dónde obtener
Suele ser un valor estático añadido durante el proceso de extracción, transformación y carga de datos (ETL).
Ejemplos
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
Última actualización de datos
LastDataUpdate
|
La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este evento desde el sistema de origen. | ||
|
Descripción
Este atributo registra la fecha y hora de la extracción de datos más reciente. Proporciona contexto sobre la frescura de los datos que se analizan, lo cual es importante para comprender la actualidad de las perspectivas del proceso. Conocer la hora de la última actualización es vital para la elaboración de informes y dashboards, ya que informa a los usuarios sobre la actualidad de los datos y ayuda a gestionar las expectativas sobre la inclusión de las actividades de incidentes más recientes.
Por qué es importante
Indica la frescura de los datos, asegurando que los usuarios comprendan cuán actual es el análisis del proceso y las perspectivas resultantes.
Dónde obtener
Este valor se genera y se registra normalmente 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 investigación. Se infiere de la primera vez que se rellena el campo 'Grupo Asignado' después de la creación del incidente. | ||
|
Por qué es importante
Este es un hito clave que significa el inicio del trabajo activo. El seguimiento del tiempo hasta la primera asignación es crítico para evaluar los tiempos de respuesta y la eficiencia del enrutamiento inicial.
Dónde obtener
Inferido del registro de auditoría ('HPD:HelpDesk_AuditLogSystem') para el formulario 'HPD:Help Desk', capturando la primera población del campo 'Assigned Group'.
Capturar
Desde la marca de tiempo cuando el campo 'Grupo Asignado' se completa por primera vez.
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 período de confirmación. Se registra cuando el estado se establece como 'Cerrado'. | ||
|
Por qué es importante
Este es el evento final definitivo para el ciclo de vida del incidente. El tiempo entre 'Resolved' y 'Closed' representa el período de confirmación del usuario y cierre administrativo.
Dónde obtener
Este evento ocurre cuando el campo 'Status' del formulario 'HPD:Help Desk' se actualiza a 'Closed'. El timestamp se registra en el campo 'Closed Date' y en el registro de auditoría.
Capturar
Desde la marca de tiempo de la 'Fecha de Cierre' o el cambio de estado a 'Cerrado'.
Tipo de evento
inferred
|
|||
|
Incidente Reportado
|
Esta actividad marca la creación inicial del registro de incidente en el sistema. Se captura explícitamente del timestamp de creación del incidente en el formulario central 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 de resolución generales y comprender las tasas de llegada de incidentes.
Dónde obtener
Este evento corresponde a la creación del registro en el formulario 'HPD:Help Desk'. El timestamp se toma típicamente del campo 'Submit Date' o 'Reported Date'.
Capturar
Desde la marca de tiempo de la 'Fecha de Envío' en el formulario HPD:Help Desk.
Tipo de evento
explicit
|
|||
|
Incidente Resuelto
|
Esta actividad marca la resolución oficial del incidente desde la perspectiva del servicio de asistencia, antes del cierre final. Se captura cuando el estado del incidente se establece en 'Resuelto'. | ||
|
Por qué es importante
Este es el hito más importante para medir el Cumplimiento de los SLA y el tiempo de resolución. Significa que el servicio ha sido restaurado para el usuario.
Dónde obtener
Este evento ocurre cuando el campo 'Status' del formulario 'HPD:Help Desk' se actualiza a 'Resolved'. El timestamp se captura en el campo 'Last Resolved Date' y en el registro de auditoría.
Capturar
Desde la marca de tiempo del cambio de estado a 'Resuelto' en el registro de auditoría.
Tipo de evento
inferred
|
|||
|
Investigación Iniciada
|
Indica que un agente de soporte ha comenzado a trabajar activamente en el incidente. Esto se infiere típicamente por un cambio de estado de 'Asignado' a 'En Curso'. | ||
|
Por qué es importante
Este hito marca la transición de la espera en una cola a un diagnóstico activo. Analizar el tiempo de espera para el inicio de la investigación ayuda a identificar cuellos de botella de recursos y apoya el dashboard de 'Cuellos de Botella en Diagnóstico e Investigación'.
Dónde obtener
Inferido de un cambio de estado en el formulario 'HPD:Help Desk'. El evento se activa cuando el campo 'Estado' cambia a 'En Curso', con el timestamp capturado del registro de auditoría.
Capturar
Inferido de un cambio de estado a 'En Curso' en el HPD:HelpDesk_AuditLogSystem.
Tipo de evento
inferred
|
|||
|
Confirmación de Usuario Recibida
|
Representa la confirmación activa del usuario de que la solución proporcionada ha resuelto su problema. Esto puede ser un evento explícito o inferido de notas o una acción del sistema relacionada antes del cierre. | ||
|
Por qué es importante
Realizar un seguimiento de esto proporciona una imagen más precisa del proceso de validación del usuario que solo esperar el autocierre. Ayuda a medir el KPI 'Tiempo Promedio de Confirmación del Usuario' e identificar brechas de comunicación.
Dónde obtener
Esto puede ser difícil de capturar de manera 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 se mueva a 'Closed'. Puede requerir un análisis del formulario 'HPD:WorkLog'.
Capturar
Inferido de entradas específicas del registro de trabajo o actualizaciones de la razón de estado antes del cierre.
Tipo de evento
inferred
|
|||
|
En Espera de Información del Cliente
|
Representa un punto donde la progresión del incidente se pausa mientras se espera información o acción del usuario. Esto se infiere de un cambio de estado a 'Pendiente'. | ||
|
Por qué es importante
Esta actividad ayuda a separar el tiempo de trabajo del agente del tiempo de espera del cliente. Analizar el tiempo pasado en este estado es crucial para comprender cómo los retrasos en la respuesta del usuario impactan en los tiempos de resolución generales.
Dónde obtener
Inferido del formulario 'HPD:Help Desk' cuando el campo 'Estado' se actualiza a 'Pendiente'. La razón específica a menudo se encuentra en el campo 'Status_Reason'.
Capturar
Inferido de un cambio de estado a 'Pendiente' en el HPD:HelpDesk_AuditLogSystem.
Tipo de evento
inferred
|
|||
|
Esperando Confirmación del Usuario
|
Ocurre después de que se ha implementado una resolución y el equipo de soporte está esperando que el usuario confirme que la solución es exitosa. Esto a menudo se representa por el propio estado de 'Resuelto', donde comienza el conteo para el cierre automático. | ||
|
Por qué es importante
Esta actividad es crucial para el dashboard de 'Retrasos en la Confirmación y Verificación del Usuario'. Ayuda a cuantificar los retrasos entre la aplicación de una solución y la obtención de la validación del usuario, lo que puede extender artificialmente el ciclo de vida del incidente.
Dónde obtener
Este estado comienza cuando el 'Status' en el formulario 'HPD:Help Desk' cambia a 'Resolved'. La duración se mide desde la 'Last Resolved Date' hasta que el incidente es 'Closed' o 'Reopened'.
Capturar
Comienza con el cambio de estado a 'Resuelto', finaliza con el cambio de estado a 'Cerrado' o 'En Progreso'.
Tipo de evento
inferred
|
|||
|
Incidente Cancelado
|
Esta actividad representa la terminación de un incidente que fue creado por error o que ya no es relevante. Se captura cuando el estado del incidente se establece en 'Cancelado'. | ||
|
Por qué es importante
Este es un estado final para un incidente, distinto de una resolución exitosa. Analizar los incidentes cancelados puede resaltar problemas con los canales de creación de incidentes o la notificación duplicada.
Dónde obtener
Inferido del formulario 'HPD:Help Desk' cuando el campo 'Estado' se actualiza a 'Cancelado'. El timestamp se captura en el registro de auditoría.
Capturar
Inferido de un cambio de estado a 'Cancelado' en el registro de auditoría.
Tipo de evento
inferred
|
|||
|
Incidente Categorizado
|
Representa el punto donde el incidente ha sido clasificado con categorizaciones operacionales y de producto, y se ha establecido una prioridad. Esto se infiere típicamente de la población o última modificación de los campos de categorización. | ||
|
Por qué es importante
Una categorización precisa y oportuna es crucial para un enrutamiento y la elaboración de informes eficientes. Analizar esta actividad ayuda a identificar retrasos o inexactitudes en el proceso de triaje inicial, lo que respalda el dashboard de 'Precisión de Categorización de Incidentes'.
Dónde obtener
Inferido del registro de auditoría ('HPD:HelpDesk_AuditLogSystem') que rastrea los cambios en campos como 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' y 'Priority' en el formulario 'HPD:Help Desk'.
Capturar
Desde la marca de tiempo de la última actualización en los campos de categorización o prioridad después de la creación.
Tipo de evento
inferred
|
|||
|
Incidente Reabierto
|
Representa un incidente que fue marcado previamente como resuelto, pero que ha sido reactivado porque el problema persiste. Esto se infiere de un cambio de estado de 'Resuelto' de nuevo a un estado activo como 'En Progreso' o 'Asignado'. | ||
|
Por qué es importante
Esta actividad mide directamente el retrabajo y la eficacia de las soluciones iniciales. Un alto volumen de incidentes reabiertos es un indicador clave de la mala calidad de la solución y apoya el KPI de 'Tasa de Retrabajo de Incidentes'.
Dónde obtener
Inferido del registro de auditoría ('HPD:HelpDesk_AuditLogSystem') al detectar un cambio de 'Estado' de 'Resuelto' a 'En Curso' o 'Asignado' para un ID de incidente determinado.
Capturar
Inferido de la transición de estado de 'Resuelto' a un estado activo.
Tipo de evento
inferred
|
|||
|
Incumplimiento de SLA
|
Este es un evento calculado que ocurre cuando el tiempo para resolver un incidente excede su objetivo definido de Service Level Agreement (SLA). Se deriva comparando el timestamp de resolución con la fecha de vencimiento del SLA. | ||
|
Por qué es importante
Esta actividad es fundamental para el dashboard de 'Resumen de Rendimiento de SLA de Incidentes' y el KPI de 'Tasa de Cumplimiento de SLA de Incidentes'. Marca directamente los incidentes que no cumplieron con los compromisos de servicio.
Dónde obtener
Calculado comparando la 'Fecha de Última Resolución' con la 'Fecha Objetivo' (Fecha de Vencimiento de SLA) en el formulario 'HPD:Help Desk'. Si el incidente aún no está resuelto, se puede calcular con respecto a la hora actual.
Capturar
Evento calculado: ocurre si 'Fecha de Última Resolución' > 'Fecha Objetivo'.
Tipo de evento
calculated
|
|||
|
Resolución Implementada
|
Esta actividad significa que el equipo de soporte ha aplicado una solución o una solución provisional. Esto a menudo se infiere cuando el estado del incidente cambia a 'Resuelto'. | ||
|
Por qué es importante
Este es un hito crítico que indica que se ha entregado una solución. Es un punto de datos clave para medir el tiempo de aplicación de una solución después de que la investigación esté completa.
Dónde obtener
Normalmente, esto se infiere cuando el 'Status' en el 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
Desde la marca de tiempo de la 'Última Fecha de Resolución' o el cambio de estado a 'Resuelto'.
Tipo de evento
inferred
|
|||
|
Transferido a Otro Grupo
|
Esta actividad ocurre cuando un incidente se reasigna de un grupo de soporte a otro. Se infiere al detectar un cambio en el campo 'Grupo Asignado' después de la asignación inicial. | ||
|
Por qué es importante
Los traspasos frecuentes indican un enrutamiento inicial incorrecto o lagunas de conocimiento. El seguimiento de esta actividad es esencial para el dashboard de 'Análisis del Ciclo de Reasignación de Incidencias' y el KPI de 'Tasa de Reasignación de Incidencias'.
Dónde obtener
Inferido 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 su primera población.
Capturar
Identifique cambios en el campo 'Grupo Asignado' después de la asignación inicial.
Tipo de evento
inferred
|
|||