Plantilla de Datos: Gestión de Incidentes

Jira Service Management
Plantilla de Datos: Gestión de Incidentes

Su Plantilla de Datos de Gestión de Incidentes

Esta plantilla ofrece un enfoque estructurado para recopilar los datos esenciales para analizar su proceso de gestión de incidentes. Describe los atributos cruciales a recopilar, las actividades clave a rastrear y proporciona orientación práctica para extraer esta información de su sistema de origen. Esto asegura que tenga todos los componentes necesarios para comenzar a optimizar sus flujos de trabajo de resolución de incidentes.
  • Atributos recomendados para recopilar
  • Actividades clave para el seguimiento
  • Guía de extracción para Jira Service Management
¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Atributos de Gestión de Incidentes

Estos son los campos de datos recomendados para su registro de eventos para un análisis exhaustivo del proceso de gestión de incidentes.
5 Requerido 7 Recomendado 12 Opcional
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
Requerido Recomendado Opcional

Actividades de Gestión de Incidentes

Estos son los pasos clave del proceso y los hitos a capturar en su registro de eventos para un descubrimiento y análisis precisos de sus workflows de resolución de incidentes.
7 Recomendado 8 Opcional
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
Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Jira Service Management