Plantilla de Datos: Gestión de Incidentes
Su Plantilla de Datos de Gestión de Incidentes
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de extracción para Jira Service Management
Atributos de Gestión de Incidentes
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
ActivityName
|
El nombre del evento específico o cambio de estado que ocurrió para el incidente. | ||
|
Descripción
La Actividad representa un paso o evento distinto en el ciclo de vida de la gestión de incidentes, como 'Incidente Creado', 'Incidente Asignado' o 'Resolución Propuesta'. Estos suelen derivarse de transiciones de estado o eventos de actualización específicos registrados en el historial o registro de cambios del incidente de Jira. Analizar la secuencia y duración de estas actividades es el objetivo principal de Process Mining, revelando el flujo de proceso real, los cuellos de botella y las desviaciones.
Por qué es importante
Las actividades forman la columna vertebral del mapa del proceso, permitiendo la visualización y el análisis del ciclo de vida de la incidencia.
Dónde obtener
Derivado del historial de incidentes de Jira y los datos del registro de cambios, capturando transiciones de estado y actualizaciones de campos clave.
Ejemplos
Incidente AsignadoInvestigación IniciadaIncidente Resuelto
|
|||
|
Hora de Inicio
EventTimestamp
|
La fecha y hora exactas en que ocurrió la actividad. | ||
|
Descripción
Este atributo registra la timestamp de cada actividad en el ciclo de vida del incidente. Es crucial para calcular duraciones, cycle times y tiempos de espera entre diferentes pasos del proceso. Las timestamps precisas permiten un análisis detallado del rendimiento, la supervisión del SLA y la identificación de bottlenecks. Todas las métricas de rendimiento, como el tiempo de resolución y la duración del diagnóstico, se derivan de estas timestamps.
Por qué es importante
Los timestamps son esenciales para calcular todas las métricas basadas en el tiempo, comprender la duración del proceso y descubrir cuellos de botella de rendimiento.
Dónde obtener
Esta es la fecha de 'created' asociada a cada entrada en el changelog o historial de la incidencia de Jira.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
ID de Incidente
IncidentId
|
El identificador único para cada ticket de incidente en Jira Service Management. | ||
|
Descripción
El ID de Incidente, a menudo referido como 'Clave de Incidente' en Jira, sirve como el identificador único principal para cada incidente reportado. Vincula todas las actividades, comentarios y cambios de estado asociados desde el momento de su creación hasta su cierre final. En Process Mining, este ID es esencial para reconstruir el ciclo de vida de principio a fin de cada incidente individual, permitiendo un análisis exhaustivo de todo el proceso.
Por qué es importante
Este es el identificador central utilizado para correlacionar todos los eventos relacionados en un único case, lo que lo convierte en la base para cualquier análisis de Process Mining.
Dónde obtener
Este es el campo estándar 'Key' para una incidencia en Jira Service Management (por ejemplo, 'ITSM-123').
Ejemplos
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Source System
SourceSystem
|
El sistema del cual se extrajo la data. | ||
|
Descripción
Este atributo identifica el origen de los datos, que en este caso es Jira Service Management. Es particularmente útil en entornos donde se combinan datos de múltiples sistemas para una vista holística del proceso. Especificar el sistema de origen asegura que la procedencia de los datos sea clara y ayuda a diagnosticar problemas de calidad o extracción de los datos. Para este modelo, el valor sería estático.
Por qué es importante
Proporciona contexto esencial sobre el origen de los datos, asegurando claridad y trazabilidad, especialmente en el análisis de múltiples sistemas.
Dónde obtener
Este es un valor estático que debe agregarse durante el proceso de extracción de datos.
Ejemplos
Jira Service ManagementJira Cloud
|
|||
|
Última actualización de datos
LastDataUpdate
|
La timestamp que indica la última vez que los datos se actualizaron desde el sistema de origen. | ||
|
Descripción
Este atributo registra cuándo se actualizó por última vez el conjunto de datos. Proporciona un contexto crítico a cualquiera que analice el proceso, asegurando que estén al tanto de la actualidad de los datos. Esto es especialmente importante para los dashboards de monitoreo continuo donde la información actualizada es crucial para tomar decisiones oportunas. El valor suele ser el mismo para todos los eventos dentro de un único lote de extracción de datos.
Por qué es importante
Informa a los usuarios sobre la puntualidad de los datos, lo cual es crucial para la relevancia y precisión del análisis.
Dónde obtener
Este es el timestamp de la ejecución de la extracción de datos, añadido durante el proceso de transformación de datos.
Ejemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Asignado
Assignee
|
El usuario actualmente asignado para trabajar en el incidente. | ||
|
Descripción
El Asignado es el agente individual o usuario responsable del incidente en un momento dado. Rastrear los cambios en el asignado es crítico para analizar las transferencias, comprender la distribución de la carga de trabajo e identificar qué individuos están involucrados en pasos de proceso específicos. Este atributo ayuda a responder preguntas sobre el rendimiento individual y la asignación de recursos dentro de los equipos de soporte.
Por qué es importante
Ayuda a rastrear la carga de trabajo individual, identificar cuellos de botella relacionados con agentes específicos y analizar el impacto de las transferencias en el tiempo de resolución.
Dónde obtener
El campo estándar Assignee de una incidencia de Jira.
Ejemplos
John SmithEmily JonesAgenteMesaDeServicio1
|
|||
|
Estado
Status
|
La etapa actual del incidente en su ciclo de vida. | ||
|
Descripción
El campo Status o Estado indica el estado actual de un incidente dentro del workflow definido, como 'Abierto', 'En progreso', 'Pendiente del cliente' o 'Resuelto'. Los cambios de estado son la fuente principal para generar el registro de eventos para el Process Mining. Analizar el tiempo dedicado a cada estado es fundamental para identificar bottlenecks y comprender dónde los incidentes pasan la mayor parte del tiempo.
Por qué es importante
Refleja directamente el progreso del incidente y es la fuente principal para identificar los pasos del proceso y los tiempos de espera.
Dónde obtener
El campo estándar Status de una incidencia de Jira.
Ejemplos
En ProgresoEsperando al clienteResueltoCerrado
|
|||
|
Fecha de Creación
CreatedDate
|
La fecha y hora en que el incidente fue creado por primera vez en el sistema. | ||
|
Descripción
Este atributo marca el inicio oficial del ciclo de vida del incidente. Es la timestamp de referencia a partir de la cual se calculan métricas generales como el tiempo total de resolución. La fecha de creación es un valor estático para cada incidente y sirve como punto de partida para todo el caso en el análisis de Process Mining.
Por qué es importante
Actúa como punto de partida para todos los cálculos del tiempo de ciclo de principio a fin y las mediciones de SLA.
Dónde obtener
El campo estándar Created de una incidencia de Jira.
Ejemplos
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Fecha de Resolución
ResolutionDate
|
La fecha y hora en que el incidente fue marcado como resuelto. | ||
|
Descripción
Este atributo captura la timestamp cuando el incidente se movió por primera vez a un estado resuelto. Marca el final de la fase de trabajo activa y es el punto final para calcular el Tiempo hasta la Resolución. Comparar la fecha de resolución con la fecha de creación proporciona la medida principal de la eficiencia del proceso. También es un componente clave para determinar el Cumplimiento del SLA.
Por qué es importante
Marca el final del proceso de resolución, lo que permite el cálculo del tiempo de ciclo total y el rendimiento del SLA.
Dónde obtener
El campo estándar Resolved de una incidencia de Jira.
Ejemplos
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Grupo de Asignación
AssignmentGroup
|
El equipo o grupo responsable de gestionar el incidente. | ||
|
Descripción
El Grupo de Asignación representa el equipo asignado al incidente. Este podría ser un nivel de soporte como 'Mesa de Ayuda L1', un equipo especializado como 'Operaciones de Red', o un equipo de desarrollo. Analizar las transiciones entre grupos de asignación es clave para comprender las escaladas de procesos y las transferencias. Permite la medición del rendimiento del equipo, la identificación de cuellos de botella a nivel de equipo y el análisis de las dependencias entre equipos.
Por qué es importante
Crucial para analizar el rendimiento del equipo, la capacidad de producción y el flujo de trabajo entre diferentes niveles de soporte o grupos especializados.
Dónde obtener
Esto a menudo se implementa como un campo personalizado en Jira, como 'Team' o 'Assignment Group'. A veces se puede derivar de los componentes de Jira o de los roles del proyecto.
Ejemplos
Soporte Nivel 1Equipo de InfraestructuraAdministradores de Base de Datos
|
|||
|
Prioridad
Priority
|
El nivel de prioridad asignado al incidente, indicando la urgencia de su resolución. | ||
|
Descripción
La prioridad determina la velocidad requerida para abordar un incidente. A menudo es una combinación de impacto y urgencia, e influye directamente en los objetivos del SLA. Analizar los incidentes por prioridad ayuda a comprender si los incidentes de alta prioridad se manejan más rápido que los de baja prioridad y si la priorización se aplica de manera consistente. Es una dimensión crítica para filtrar y comparar el rendimiento del proceso.
Por qué es importante
Esencial para el análisis del rendimiento de los SLA y para verificar que los recursos se asignen correctamente a los incidentes más críticos.
Dónde obtener
El campo estándar Priority de una incidencia de Jira.
Ejemplos
Más AltaAltoMedioBajo
|
|||
|
Tiempo de Ciclo de Resolución
IncidentResolutionCycleTime
|
El tiempo total transcurrido desde la creación hasta la resolución del incidente. | ||
|
Descripción
Esta es una métrica calculada que representa la duración desde la 'CreatedDate' hasta la 'ResolutionDate'. Es uno de los KPIs más importantes en la gestión de incidentes, midiendo directamente la eficiencia de todo el proceso. Analizar esta métrica en diferentes dimensiones, como la prioridad, el grupo de asignación o el componente, ayuda a identificar qué factores tienen el mayor impacto en el rendimiento.
Por qué es importante
Mide directamente la eficiencia de principio a fin del proceso de gestión de incidentes y es un KPI principal para el seguimiento del rendimiento.
Dónde obtener
Calculado como ('ResolutionDate' - 'CreatedDate').
Ejemplos
2h 30m1d 4h5d 1h 15m
|
|||
|
¿Es Retrabajo?
IsRework
|
Un indicador de si la incidencia ha pasado por un retrabajo, como ser reabierta. | ||
|
Descripción
Este atributo booleano calculado identifica los incidentes que han sido devueltos a una etapa anterior del proceso, más comúnmente al ser reabiertos después de haber sido resueltos. Los bucles de retrabajo son una fuente significativa de ineficiencia y de insatisfacción del cliente. Esta marca permite cuantificar fácilmente la tasa de retrabajo y ayuda a enfocar el análisis en por qué los incidentes no se resuelven correctamente la primera vez.
Por qué es importante
Destaca los problemas de calidad del proceso y las ineficiencias al señalar incidentes que requieren trabajo repetido, apoyando directamente el análisis de reprocesos.
Dónde obtener
Calculado al detectar secuencias específicas de transiciones de estado en el registro de eventos, como 'Resuelto' -> 'Reabierto'.
Ejemplos
truefalse
|
|||
|
Categoría de Causa Raíz
RootCauseCategory
|
La clasificación de la causa raíz subyacente del incidente. | ||
|
Descripción
Este atributo captura la razón fundamental por la que ocurrió el incidente, como 'Defecto de Software', 'Fallo de Hardware' o 'Error del usuario'. Normalmente se rellena después de la investigación y es esencial para una gestión de problemas eficaz y la prevención de futuros incidentes. Analizar las categorías de causas raíz ayuda a identificar debilidades sistémicas y priorizar iniciativas de mejora. Una alta tasa de causas raíz 'Desconocidas' puede indicar la necesidad de mejores procesos de investigación.
Por qué es importante
Permite el análisis de la causa raíz, ayudando a pasar de un enfoque reactivo a uno proactivo mediante la identificación y el abordaje de las fuentes de los incidentes.
Dónde obtener
Este es casi siempre un campo personalizado en Jira. El nombre y las opciones dependen en gran medida de la configuración específica de la organización.
Ejemplos
Error de ConfiguraciónInterrupción de RedError de Software
|
|||
|
Componente
Component
|
El sistema, la aplicación o parte de la infraestructura afectada por el incidente. | ||
|
Descripción
Los Componentes son subsecciones de un proyecto Jira utilizadas para agrupar incidentes en partes más pequeñas, como 'Interfaz de Usuario', 'Base de Datos' o 'API'. Analizar los incidentes por componente ayuda a identificar qué partes de un sistema son más propensas a problemas. Esta información es valiosa para el análisis de la causa raíz y puede guiar los esfuerzos para la mejora del servicio o la reducción de la deuda técnica.
Por qué es importante
Permite filtrar y analizar según el producto o área de sistema específica afectada, lo que ayuda a identificar puntos críticos tecnológicos.
Dónde obtener
El campo estándar Components de una incidencia de Jira.
Ejemplos
Servicio de AutenticaciónDashboard de InformesApp móvil
|
|||
|
ID de Problema Vinculado
LinkedProblemId
|
El identificador de un ticket de problema vinculado a este incidente. | ||
|
Descripción
Los incidentes que son síntomas de un problema subyacente más grande suelen estar vinculados a un ticket de Problema. Este campo almacena el ID de ese Problema asociado. Analizar estos vínculos ayuda a comprender la relación entre incidentes y problemas, medir la efectividad del proceso de gestión de problemas e identificar incidentes recurrentes que requieren una solución permanente.
Por qué es importante
Conecta los incidentes con los problemas subyacentes, lo que permite analizar la eficacia con la que la organización aborda las causas raíz para prevenir futuros incidentes.
Dónde obtener
Esta información se almacena en la sección 'Issue Links' de una incidencia de Jira.
Ejemplos
PROB-123PROB-456Ninguno
|
|||
|
Incumplimiento de SLA
SlaBreach
|
Un indicador de si el tiempo de resolución de la incidencia excedió el objetivo del SLA. | ||
|
Descripción
Este atributo booleano calculado indica si un incidente ha incumplido su SLA de 'Tiempo hasta la Resolución'. Es verdadero si el 'IncidentResolutionCycleTime' es mayor que el 'TimeToResolutionTarget'. Esta marca simplifica el análisis y la visualización, permitiendo un fácil filtrado y agregación para calcular el KPI general de Tasa de Incumplimiento de SLA. Es la medida clave de resultado para el dashboard de Monitoreo del Rendimiento del SLA.
Por qué es importante
Proporciona un resultado claro y binario para el rendimiento del SLA, lo que facilita el cálculo de las tasas de incumplimiento y la identificación de áreas problemáticas.
Dónde obtener
Calculado como ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Ejemplos
truefalse
|
|||
|
Objetivo de Tiempo de Resolución
TimeToResolutionTarget
|
La duración objetivo del SLA para resolver el incidente. | ||
|
Descripción
Este atributo define el tiempo máximo esperado dentro del cual debe resolverse un incidente de cierta prioridad o tipo. Es el punto de referencia contra el cual se mide el tiempo real de resolución para determinar el Cumplimiento del SLA. Este valor se suele establecer dinámicamente basándose en reglas que consideran factores como la prioridad, la severidad o el tipo de incidencia. Es fundamental para cualquier dashboard de monitoreo del rendimiento del SLA.
Por qué es importante
Proporciona el punto de referencia para medir el cumplimiento del SLA, formando la base para el KPI de Tasa de Incumplimiento de SLA de Incidentes.
Dónde obtener
Esto se deriva de la configuración de SLA dentro de Jira Service Management. Se debe identificar el objetivo específico (por ejemplo, 'Time to resolution').
Ejemplos
4h8h3d
|
|||
|
Recuento de Traspasos
HandoffCount
|
El número de veces que el incidente fue reasignado a un grupo o usuario diferente. | ||
|
Descripción
Esta métrica calculada cuenta el número de veces que los campos 'Assignee' o 'AssignmentGroup' cambiaron durante el ciclo de vida del incidente. Un alto número de traspasos (handoffs) a menudo indica ineficiencia en el proceso, falta de resolución en la primera llamada o lagunas de conocimiento, lo que conduce a tiempos de resolución más largos. Analizar este KPI ayuda a optimizar el proceso de asignación y a mejorar la colaboración del equipo.
Por qué es importante
Cuantifica la fricción y la ineficiencia del proceso causadas por las reasignaciones, ayudando a identificar oportunidades de mejora del proceso.
Dónde obtener
Calculado contando el número de cambios en el campo 'Responsable' o 'Grupo de Asignación' en el registro de cambios del incidente.
Ejemplos
015
|
|||
|
Reportero
Reporter
|
El usuario que inicialmente creó o reportó el incidente. | ||
|
Descripción
El Reporter o Solicitante es la persona, a menudo un usuario final u otro sistema, que registró el incidente por primera vez. Analizar los incidentes por reporter puede ayudar a identificar usuarios o departamentos que experimentan problemas con frecuencia. También se puede utilizar para comprender los patrones de comunicación, especialmente al analizar actividades como 'Esperando al Cliente' y 'Cliente Respondió'.
Por qué es importante
Ayuda a analizar las fuentes de incidentes, identificar patrones relacionados con usuarios o departamentos específicos y comprender los retrasos en la interacción con el cliente.
Dónde obtener
El campo estándar Reporter de una incidencia de Jira.
Ejemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Resolución
Resolution
|
El resultado final o la razón para resolver el incidente. | ||
|
Descripción
El campo Resolution o Resolución explica por qué un incidente se movió a un estado resuelto. Las resoluciones comunes incluyen 'Corregido', 'Duplicado', 'No se hará' o 'No se puede reproducir'. Analizar la distribución de los tipos de resolución puede brindar información sobre la calidad de los informes entrantes y la eficacia del proceso de resolución. Por ejemplo, un gran número de resoluciones 'Duplicadas' puede indicar un problema en la fase de creación o clasificación del incidente.
Por qué es importante
Proporciona contexto al resultado de un incidente, ayudando a categorizar las resoluciones e identificar tendencias en cómo se cierran los incidentes.
Dónde obtener
El campo estándar Resolution de una incidencia de Jira. Este campo se suele establecer cuando una incidencia pasa a una categoría de estado 'Hecho'.
Ejemplos
HechoSolucionadoDuplicadoNo Se Arreglará
|
|||
|
Severidad
Severity
|
La medida del impacto en el negocio del incidente. | ||
|
Descripción
La Severidad define cuánto impacto tiene un incidente en el negocio, desde un solo usuario afectado hasta una interrupción crítica del sistema. Mientras que la Prioridad dicta el orden del trabajo, la Severidad informa el impacto general en el negocio. Analizar por severidad ayuda a comprender el rendimiento del proceso para los incidentes que más importan al negocio y a menudo se utiliza en combinación con la Prioridad para un análisis más matizado.
Por qué es importante
Proporciona una visión del impacto empresarial, permitiendo un análisis enfocado en los incidentes más perjudiciales para las operaciones comerciales.
Dónde obtener
Típicamente un campo personalizado en Jira, ya que no es un campo de sistema estándar. Consulte la configuración del proyecto de Jira Service Management.
Ejemplos
CríticoMayorMenorTrivial
|
|||
|
Tipo de Incidente
IssueType
|
El tipo de incidencia, como Incidente, Solicitud de Servicio o Problema. | ||
|
Descripción
Jira utiliza Tipos de Incidente (Issue Types) para distinguir entre diferentes tipos de tareas. En un contexto de Gestión de Incidentes, el tipo principal es 'Incidente', pero otros como 'Subtarea' (Sub-task) también podrían ser relevantes. Este atributo es crucial para filtrar el conjunto de datos e incluir solo incidentes, asegurando que el análisis de Process Mining se centre en el proceso correcto.
Por qué es importante
Asegura que el análisis se limite correctamente a los incidentes, separándolos de otros tipos de trabajo como las solicitudes de servicio o los cambios.
Dónde obtener
El campo estándar Issue Type de una incidencia de Jira.
Ejemplos
IncidenteSoporte de TIBug
|
|||
|
Tipo de Solicitud de Cliente
CustomerRequestType
|
El tipo específico de solicitud enviada por el cliente a través del portal de servicios. | ||
|
Descripción
Este campo clasifica las solicitudes desde el punto de vista del cliente, tal como se presentan en el portal de Jira Service Management (por ejemplo, 'Reportar un problema del sistema'). Proporciona una clasificación del incidente fácil de usar, que puede diferir del 'Issue Type' interno. Analizar este atributo puede ofrecer información sobre cómo los clientes perciben y reportan los problemas, ayudando a mejorar el diseño del portal y la oferta de servicios.
Por qué es importante
Proporciona una visión centrada en el cliente de las categorías de incidentes, lo cual es útil para analizar la demanda y mejorar la experiencia del cliente.
Dónde obtener
El campo 'Customer Request Type', específico de los proyectos de Jira Service Management.
Ejemplos
Obtener ayuda de TI > Informar de un problema del sistemaCorreo Electrónico > Solicitud de Acceso
|
|||
Actividades de Gestión de Incidentes
| Actividad | Descripción | ||
|---|---|---|---|
|
Esperando al Cliente
|
Marca un punto donde el equipo de soporte está esperando información o una acción del cliente. Esto se infiere de una transición de estado a un estado de espera dedicado, como 'Esperando cliente'. | ||
|
Por qué es importante
Aislar este tiempo 'en espera' es crítico para una medición precisa del SLA, ya que a menudo se excluye de los cálculos del tiempo de resolución. Ayuda a analizar los retrasos en la respuesta del cliente.
Dónde obtener
Se infiere del historial de cambios de estado del incidente. El evento corresponde a la marca de tiempo (timestamp) cuando el estado cambia a 'Esperando al cliente' o un estado similar.
Capturar
Identificar el timestamp de la transición de estado a 'Esperando al cliente'.
Tipo de evento
inferred
|
|||
|
Incidente Cerrado
|
Representa el cierre administrativo final del ticket del incidente después de haber sido resuelto y verificado. Esto se infiere de la transición de estado a 'Cerrado'. | ||
|
Por qué es importante
Este es el evento terminal del proceso. Analizar el tiempo entre 'Resolved' y 'Closed' puede revelar retrasos en la limpieza administrativa o en los procesos de confirmación del usuario.
Dónde obtener
Se infiere del historial de cambios de estado del incidente. El evento corresponde a la marca de tiempo (timestamp) cuando el estado pasa al estado final 'Cerrado'.
Capturar
Identificar el timestamp de la transición de estado a 'Cerrado'.
Tipo de evento
inferred
|
|||
|
Incidente Creado
|
Marca el inicio oficial del ciclo de vida del incidente cuando se envía un informe y se crea una nueva incidencia en Jira. Este evento se captura explícitamente cuando se registra una nueva incidencia del tipo 'Incidente' en el sistema. | ||
|
Por qué es importante
Este es el evento de inicio principal del proceso. Analizar el tiempo desde esta actividad hasta la resolución es fundamental para medir el cycle time general y el cumplimiento del SLA.
Dónde obtener
Este es un evento explícito capturado del 'created' timestamp de la incidencia en Jira. El evento de creación de la incidencia se registra en el historial de la incidencia.
Capturar
Utilice el timestamp de creación de la incidencia.
Tipo de evento
explicit
|
|||
|
Incidente Reasignado
|
Ocurre cuando un incidente se transfiere de un agente o grupo a otro después de la asignación inicial. Este evento se deduce de cualquier cambio en el campo 'Asignado a' o 'Grupo Asignado'. | ||
|
Por qué es importante
El seguimiento de las reasignaciones es crucial para el análisis de traspasos (handoffs). Un alto número de reasignaciones a menudo indica ineficiencias en el proceso, lagunas de conocimiento o un enrutamiento inicial incorrecto, lo que conduce a retrasos en la resolución.
Dónde obtener
Se infiere del historial del incidente al detectar cualquier actualización en el campo 'Asignado a' después de que este fuera poblado por primera vez. Cada cambio constituye un evento de reasignación.
Capturar
Identificar cambios posteriores en el campo 'Asignado' después de la asignación inicial.
Tipo de evento
inferred
|
|||
|
Incidente Resuelto
|
Esta actividad marca la confirmación de que el incidente se ha resuelto con éxito y el servicio se ha restaurado. A menudo coincide con la transición al estado 'Resuelto'. | ||
|
Por qué es importante
Este es el hito de éxito principal en el proceso. La duración hasta este punto es el KPI más común, representando el Time to Resolution (TTR).
Dónde obtener
Se infiere del cambio de estado a 'Resuelto'. En muchos flujos de trabajo (workflows), este es el mismo evento que 'Resolución Propuesta', representando el punto principal de resolución.
Capturar
Identificar el timestamp de la transición de estado a 'Resuelto'.
Tipo de evento
inferred
|
|||
|
Investigación Iniciada
|
Indica que un agente asignado ha comenzado a trabajar activamente en el diagnóstico del incidente. Esto se infiere típicamente cuando el estado del incidente pasa de 'Abierto' o 'Nuevo' a 'En Curso'. | ||
|
Por qué es importante
Este hito clave marca el inicio de los esfuerzos de resolución activos. Medir el tiempo hasta esta actividad ayuda a identificar retrasos iniciales en la cola y problemas de disponibilidad de recursos.
Dónde obtener
Se infiere del historial de cambios de estado del incidente. La marca de tiempo (timestamp) del evento es cuando el estado transiciona a un estado que representa trabajo activo, como 'En Curso'.
Capturar
Identificar el timestamp de la transición de estado a 'En Progreso'.
Tipo de evento
inferred
|
|||
|
Resolución Propuesta
|
Esta actividad indica que se ha identificado e implementado una resolución, y el incidente está a la espera de confirmación o validación final. Se infiere de la transición de estado a 'Resuelto'. | ||
|
Por qué es importante
Este es un hito importante que significa el fin del trabajo activo por parte del equipo de soporte. A menudo es el evento que detiene el reloj del SLA.
Dónde obtener
Se infiere del historial de cambios de estado del incidente. La marca de tiempo (timestamp) del evento es cuando el estado transiciona a 'Resuelto' o a un estado equivalente.
Capturar
Identificar el timestamp de la transición de estado a 'Resuelto'.
Tipo de evento
inferred
|
|||
|
Cliente Respondió
|
Indica que el cliente ha proporcionado la información solicitada y el incidente puede continuar. Esto se infiere cuando el estado cambia de 'Esperando al cliente' a un estado activo. | ||
|
Por qué es importante
Esta actividad marca el final de un retraso inducido por el cliente. Analizar la duración entre 'Esperando al Cliente' y este evento revela el tiempo promedio de respuesta del cliente.
Dónde obtener
Se infiere del historial de cambios de estado del incidente. El evento ocurre cuando el estado transiciona de 'Esperando al cliente' a un estado como 'En Curso', a menudo desencadenado por el cliente al añadir un comentario.
Capturar
Detectar cambio de estado de 'Esperando cliente' a 'En Progreso'.
Tipo de evento
inferred
|
|||
|
Comentario Añadido
|
Representa cualquier evento de comunicación o toma de notas donde un usuario añade un comentario al ticket del incidente. Este es un evento explícito capturado cada vez que se publica un comentario. | ||
|
Por qué es importante
Analizar la frecuencia de los comentarios puede ofrecer información sobre los patrones de comunicación, la eficiencia de la colaboración y la complejidad de un incidente. Puede resaltar los incidentes que requieren una comunicación excesiva.
Dónde obtener
Este es un evento explícito. Jira almacena cada comentario con un timestamp y autor, disponible a través del historial de comentarios de la incidencia o de la API.
Capturar
Utilice el timestamp de cada comentario añadido a la incidencia.
Tipo de evento
explicit
|
|||
|
Escalado a Equipo Especializado
|
Significa que el incidente ha sido escalado a un equipo especializado (p. ej., Nivel 2, Desarrollo) para soporte avanzado. Esto se infiere de un cambio en un campo personalizado de 'Equipo de Soporte' o de una reasignación específica. | ||
|
Por qué es importante
Destaca los incidentes que requieren conocimiento especializado y rastrea el flujo entre los diferentes niveles de soporte. Esto ayuda a identificar cuellos de botella dentro de los equipos especializados y analizar los patrones de escalado.
Dónde obtener
Se infiere del historial del incidente mediante el seguimiento de cambios en un campo personalizado que representa el equipo asignado o al identificar un cambio de 'Asignado a' a un miembro de un grupo especialista conocido.
Capturar
Detectar un cambio en un campo personalizado para 'Equipo Asignado' o cambios específicos de responsable.
Tipo de evento
inferred
|
|||
|
Incidencia Priorizada
|
Representa la asignación de la prioridad y/o severidad del incidente, lo que determina su urgencia e impacto en el negocio. Esto generalmente se infiere de la primera vez que los campos 'Prioridad' o 'Severidad' se rellenan o actualizan después de la creación. | ||
|
Por qué es importante
El seguimiento de la priorización ayuda a analizar si los incidentes se evalúan de forma rápida y consistente. Los retrasos en este paso pueden afectar directamente los cálculos de SLA y la asignación de recursos.
Dónde obtener
Se infiere del registro de historial del incidente, que rastrea los cambios en todos los campos. Busque la primera actualización en el campo 'Prioridad' o un campo personalizado de 'Severidad' después del evento de creación del incidente.
Capturar
Detectar el primer cambio en el campo 'Prioridad' en el historial del incidente.
Tipo de evento
inferred
|
|||
|
Incidente Asignado
|
Esta actividad significa la asignación inicial del incidente a un agente o grupo de soporte para su gestión. Se captura rastreando la primera vez que se rellena el campo Assignee o 'Grupo Asignado'. | ||
|
Por qué es importante
Mide el tiempo de respuesta inicial y de asignación, un componente clave de las métricas de SLA. Ayuda a identificar retrasos antes de que comience la investigación activa.
Dónde obtener
Se infiere del historial del incidente al identificar el primer cambio en el campo 'Asignado a' donde el valor anterior era 'Sin asignar'.
Capturar
Detectar la primera actualización en el campo 'Responsable' en el historial del incidente.
Tipo de evento
inferred
|
|||
|
Incidente Reabierto
|
Representa una situación en la que un incidente previamente resuelto se reactiva porque el problema reapareció o la solución fue ineficaz. Esto se infiere de un cambio de estado de 'Resuelto' o 'Cerrado' a un estado abierto. | ||
|
Por qué es importante
Los incidentes reabiertos son una medida directa de la calidad de la resolución y un indicador principal de retrabajo. Analizar estos eventos ayuda a identificar cierres prematuros y soluciones ineficaces.
Dónde obtener
Se infiere del historial de cambios de estado del incidente. El evento se registra cuando el estado pasa de un estado terminal como 'Resuelto' o 'Cerrado' de nuevo a 'Abierto' o 'En Curso'.
Capturar
Detectar cambio de estado de 'Resuelto' o 'Cerrado' a un estado abierto.
Tipo de evento
inferred
|
|||
|
Solución Provisional Proporcionada
|
Representa la implementación de una solución temporal para restaurar el servicio mientras se desarrolla una solución permanente. Esto puede inferirse de un cambio de estado o de un comentario específico. | ||
|
Por qué es importante
Medir el tiempo para proporcionar una solución provisional es un indicador clave de la velocidad de restauración del servicio. Ayuda a diferenciar entre la mitigación temporal y la resolución permanente.
Dónde obtener
Esto a menudo se infiere. Podría ser una transición a un estado 'Workaround Provided' o la adición de un comentario público que contenga palabras clave específicas como 'workaround'.
Capturar
Identificar una transición de estado específica o una palabra clave en un comentario.
Tipo de evento
inferred
|
|||
|
Vinculado a Ticket de Problema
|
Ocurre cuando un incidente se vincula a una incidencia de tipo 'Problema' para el análisis de causa raíz. Este evento se captura explícitamente cuando se crea un vínculo 'relacionado con' o 'causado por' a una incidencia de tipo 'Problema'. | ||
|
Por qué es importante
El seguimiento de este enlace es esencial para comprender la eficacia con la que la organización realiza la transición de la mitigación de incidentes al análisis de la causa raíz y la prevención.
Dónde obtener
Este es un evento explícito registrado en el historial de enlaces de la incidencia. Cada creación de enlace tiene un timestamp y se puede filtrar para enlaces al tipo de incidencia 'Problem'.
Capturar
Utilice el timestamp de la creación de un enlace de incidencia a un tipo de incidencia 'Problem'.
Tipo de evento
explicit
|
|||