Su Template de datos para la gestión de incidencias

Jira Service Management
Su Template de datos para la gestión de incidencias

Su Template de datos para la gestión de incidencias

Este Template ofrece un método estructurado para recopilar los datos esenciales para analizar el proceso de gestión de incidencias. Indica qué atributos conviene recopilar, qué actividades clave se deben seguir y ofrece instrucciones prácticas para extraer esta información del sistema de origen. Así dispondrá de los elementos necesarios para empezar a optimizar los flujos de trabajo de resolución de incidencias.
  • Atributos recomendados para recopilar
  • Actividades clave que conviene seguir
  • Instrucciones de extracción para Jira Service Management
¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Atributos de gestión de incidencias

Estos son los campos de datos recomendados para incluir en el registro de eventos y analizar en profundidad el proceso de gestión de incidencias.
5 Obligatorio 6 Recomendado 12 Opcional
Nombre Descripción
Actividad
ActivityName
Nombre del evento específico o del cambio de estado que se produjo en la incidencia.
Descripción

La actividad representa un paso o evento concreto del ciclo de vida de la gestión de incidencias, como «Incidencia creada», «Incidencia asignada» o «Solución propuesta». Por lo general, se obtiene de las transiciones de estado o de eventos de actualización registrados en el historial o el registro de cambios de la incidencia en Jira. Analizar la secuencia y la duración de estas actividades es el objetivo principal de Process Mining, ya que permite conocer el flujo real del proceso, los cuellos de botella y las desviaciones.

Por qué es importante

Las actividades son la base del mapa de procesos y permiten visualizar y analizar el ciclo de vida de las incidencias.

Dónde obtenerlo

Se obtiene del historial de la incidencia y de los datos del registro de cambios de Jira, que recogen las transiciones de estado y las actualizaciones de campos clave.

Ejemplos
Incidente asignadoInvestigación iniciadaIncidente resuelto
Hora de inicio
EventTimestamp
Fecha y hora exactas en que se produjo la actividad.
Descripción

Este atributo registra la marca de tiempo de cada actividad del ciclo de vida de la incidencia. Es fundamental para calcular la duración, el tiempo de ciclo y los tiempos de espera entre los distintos pasos del proceso. Las marcas de tiempo precisas permiten analizar el rendimiento en detalle, supervisar los SLA e identificar cuellos de botella. Todas las métricas de rendimiento, como el tiempo de resolución y la duración del diagnóstico, se calculan a partir de estas marcas de tiempo.

Por qué es importante

Las marcas de tiempo son esenciales para calcular todas las métricas basadas en el tiempo, comprender la duración del proceso y detectar cuellos de botella que afectan al rendimiento.

Dónde obtenerlo

Es la fecha de «creación» asociada a cada entrada del historial o del registro de cambios de la incidencia en Jira.

Ejemplos
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
ID de incidencia
IncidentId
Identificador único de cada ticket de incidencia en Jira Service Management.
Descripción

El ID de incidencia, conocido también como clave de incidencia en Jira, es el identificador único principal de cada incidencia reportada. Vincula todas las actividades, los comentarios y los cambios de estado relacionados, desde la creación hasta el cierre definitivo. En Process Mining, este ID es esencial para reconstruir el ciclo de vida completo de cada incidencia y analizar el proceso de principio a fin.

Por qué es importante

Es el identificador principal que permite relacionar todos los eventos vinculados en un único caso y constituye la base de cualquier análisis de Process Mining.

Dónde obtenerlo

Es el campo estándar «Clave» de una incidencia en Jira Service Management (por ejemplo, «ITSM-123»).

Ejemplos
INC-10234HELPDESK-5678OPS-9901
Sistema de origen
SourceSystem
Sistema del que se extrajeron los datos.
Descripción

Este atributo identifica el origen de los datos, que en este caso es Jira Service Management. Resulta especialmente útil cuando se combinan datos de varios sistemas para obtener una visión integral del proceso. Especificar el sistema de origen permite conocer la procedencia de los datos y facilita el diagnóstico de problemas de calidad o extracción. En este modelo, el valor sería estático.

Por qué es importante

Aporta contexto esencial sobre el origen de los datos y garantiza su claridad y trazabilidad, especialmente al analizar varios sistemas.

Dónde obtenerlo

Es un valor estático que debe añadirse durante la extracción de datos.

Ejemplos
Jira Service ManagementJira Cloud
Última actualización de los datos
LastDataUpdate
Marca de tiempo que indica cuándo se actualizaron por última vez los datos desde el sistema de origen.
Descripción

Este atributo registra cuándo se actualizó el conjunto de datos por última vez. Aporta un contexto fundamental para quienes analizan el proceso, ya que indica si los datos están actualizados. Esto es especialmente importante en los Dashboards de seguimiento continuo, donde disponer de información reciente es clave para tomar decisiones a tiempo. Por lo general, el valor es el mismo para todos los eventos de un mismo lote de extracción de datos.

Por qué es importante

Informa sobre la actualidad de los datos, un aspecto fundamental para que el análisis sea pertinente y preciso.

Dónde obtenerlo

Es la marca de tiempo de la ejecución de extracción de datos, que se añade durante el proceso de transformación.

Ejemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Estado
Status
Etapa actual de la incidencia en su ciclo de vida.
Descripción

El campo Estado indica la situación actual de una incidencia dentro del flujo de trabajo definido, por ejemplo, «Abierta», «En curso», «Pendiente del cliente» o «Resuelta». Los cambios de estado son la fuente principal para generar el registro de actividades que se utiliza en Process Mining. Analizar el tiempo que las incidencias permanecen en cada estado es fundamental para detectar cuellos de botella y saber en qué etapas pasan más tiempo.

Por qué es importante

Refleja directamente el avance de la incidencia y es la fuente principal para identificar los pasos del proceso y los tiempos de espera.

Dónde obtenerlo

El campo estándar «Estado» de una incidencia en Jira.

Ejemplos
En cursoEn espera del clienteResueltoCerrado
Fecha de creación
CreatedDate
Fecha y hora en que se creó la incidencia por primera vez en el sistema.
Descripción

Este atributo marca el inicio oficial del ciclo de vida de la incidencia. Es la marca de tiempo de referencia para calcular métricas generales, como el tiempo total de resolución. La fecha de creación es un valor estático para cada incidencia y marca el inicio de todo el caso en el análisis de Process Mining.

Por qué es importante

Es el punto de partida para calcular el tiempo de ciclo de principio a fin y medir los SLA.

Dónde obtenerlo

El campo estándar «Creado» de una incidencia en Jira.

Ejemplos
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Fecha de resolución
ResolutionDate
Fecha y hora en que la incidencia se marcó como resuelta.
Descripción

Este atributo registra la marca de tiempo en que la incidencia pasó por primera vez a un estado resuelto. Marca el final de la fase de trabajo activo y sirve como punto final para calcular el tiempo de resolución. Comparar la fecha de resolución con la fecha de creación permite medir principalmente la eficiencia del proceso. También es un dato clave para determinar el cumplimiento del SLA.

Por qué es importante

Marca el final del proceso de resolución y permite calcular el tiempo de ciclo total y el rendimiento del SLA.

Dónde obtenerlo

El campo estándar «Resuelto» de una incidencia en Jira.

Ejemplos
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Grupo de asignación
AssignmentGroup
Equipo o grupo responsable de gestionar la incidencia.
Descripción

El grupo de asignación representa al equipo asignado a la incidencia. Puede ser un nivel de soporte, como «Mesa de ayuda de nivel 1», un equipo especializado, como «Operaciones de red», o un equipo de desarrollo. Analizar los cambios entre grupos de asignación es clave para comprender los escalamientos y traspasos del proceso. También permite medir el rendimiento de los equipos, detectar cuellos de botella a nivel de equipo y analizar las dependencias entre equipos.

Por qué es importante

Es fundamental para analizar el rendimiento y la capacidad de los equipos, así como el flujo de trabajo entre los distintos niveles de soporte o grupos especializados.

Dónde obtenerlo

A menudo se implementa como un campo personalizado en Jira, por ejemplo, «Equipo» o «Grupo de asignación». En algunos casos, puede obtenerse de los componentes de Jira o de los roles del proyecto.

Ejemplos
Soporte de nivel 1Equipo de infraestructuraAdministradores de bases de datos
Persona asignada
Assignee
Usuario asignado actualmente para trabajar en la incidencia.
Descripción

La persona asignada es el agente o usuario responsable de la incidencia en un momento determinado. Hacer un seguimiento de los cambios de asignación es fundamental para analizar los traspasos, comprender cómo se distribuye la carga de trabajo e identificar quiénes participan en cada paso del proceso. Este atributo ayuda a responder preguntas sobre el rendimiento individual y la asignación de recursos en los equipos de soporte.

Por qué es importante

Ayuda a hacer un seguimiento de la carga de trabajo individual, detectar cuellos de botella relacionados con agentes concretos y analizar cómo afectan los traspasos al tiempo de resolución.

Dónde obtenerlo

El campo estándar «Persona asignada» de una incidencia en Jira.

Ejemplos
John SmithEmily JonesAgente de ServiceDesk 1
Prioridad
Priority
Nivel de prioridad asignado a la incidencia, que indica la urgencia con la que debe resolverse.
Descripción

La prioridad determina la rapidez con la que debe atenderse una incidencia. A menudo combina el impacto y la urgencia, y afecta directamente a los objetivos de SLA. Analizar las incidencias por prioridad permite comprobar si las de prioridad alta se atienden más rápido que las de prioridad baja y si la priorización se aplica de forma coherente. Es una dimensión clave para filtrar y comparar el rendimiento del proceso.

Por qué es importante

Es esencial para analizar el rendimiento del SLA y comprobar que los recursos se asignen correctamente a las incidencias más críticas.

Dónde obtenerlo

El campo estándar «Prioridad» de una incidencia en Jira.

Ejemplos
MáximaAltaMediaBaja
Categoría de la causa raíz
RootCauseCategory
Clasificación de la causa raíz de la incidencia.
Descripción

Este atributo registra el motivo fundamental por el que se produjo la incidencia, como «Defecto de software», «Fallo de hardware» o «Error del usuario». Por lo general, se completa después de la investigación y es esencial para gestionar los problemas de forma eficaz y prevenir futuras incidencias. Analizar las categorías de causas raíz ayuda a detectar debilidades sistémicas y a priorizar iniciativas de mejora. Una proporción elevada de causas raíz «Desconocidas» puede indicar que es necesario mejorar los procesos de investigación.

Por qué es importante

Permite analizar las causas raíz y pasar de un enfoque reactivo a uno proactivo, al identificar y abordar el origen de las incidencias.

Dónde obtenerlo

Casi siempre es un campo personalizado de 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 la redError de software
Componente
Component
Sistema, aplicación o parte de la infraestructura afectada por la incidencia.
Descripción

Los componentes son subdivisiones de un proyecto de Jira que permiten agrupar las incidencias en áreas más pequeñas, como «Interfaz de usuario», «Base de datos» o «API». Analizar las incidencias por componente ayuda a identificar qué partes de un sistema presentan más problemas. Esta información resulta útil para analizar las causas raíz y orientar las iniciativas de mejora del servicio o reducción de la deuda técnica.

Por qué es importante

Permite filtrar y analizar los datos según el producto o área del sistema afectada, lo que ayuda a identificar los puntos problemáticos de la tecnología.

Dónde obtenerlo

El campo estándar «Componentes» de una incidencia en Jira.

Ejemplos
Servicio de autenticaciónDashboard de informesAplicación móvil
Es retrabajo
IsRework
Indicador que señala si la incidencia ha requerido retrabajo, por ejemplo, si se ha vuelto a abrir.
Descripción

Este atributo booleano calculado identifica las incidencias que han vuelto a una etapa anterior del proceso, normalmente porque se reabrieron después de resolverse. Los ciclos de retrabajo son una fuente importante de ineficiencia e insatisfacción del cliente. Este indicador permite cuantificar fácilmente la tasa de retrabajo y centrar el análisis en los motivos por los que las incidencias no se resuelven correctamente a la primera.

Por qué es importante

Permite detectar problemas de calidad e ineficiencias en el proceso al señalar las incidencias que requieren trabajo repetido, y facilita directamente el análisis del retrabajo.

Dónde obtenerlo

Se calcula detectando secuencias específicas de cambios de estado en el registro de eventos, como 'Resolved' -> 'Reopened'.

Ejemplos
truefalse
Gravedad
Severity
Medida del impacto de la incidencia en el negocio.
Descripción

La gravedad indica cuánto afecta una incidencia al negocio, desde un problema que afecta a una sola persona hasta la interrupción de un sistema crítico. La prioridad determina el orden de atención, mientras que la gravedad refleja el impacto general en el negocio. Analizar las incidencias por gravedad permite comprender el rendimiento del proceso en los casos de mayor importancia para el negocio. A menudo se combina con la prioridad para obtener un análisis más detallado.

Por qué es importante

Ofrece una perspectiva del impacto en el negocio y permite centrar el análisis en las incidencias que más perjudican las operaciones.

Dónde obtenerlo

Suele ser un campo personalizado de Jira, ya que no forma parte de los campos estándar del sistema. Consulte la configuración del proyecto de Jira Service Management.

Ejemplos
CríticoGraveLeveInsignificante
ID del problema vinculado
LinkedProblemId
Identificador del ticket de problema vinculado a esta incidencia.
Descripción

Las incidencias que son síntomas de un problema subyacente de mayor alcance suelen vincularse a un ticket de problema. Este campo almacena el ID del problema asociado. Analizar estos vínculos ayuda a comprender la relación entre las incidencias y los problemas, medir la eficacia del proceso de gestión de problemas e identificar incidencias recurrentes que requieren una solución permanente.

Por qué es importante

Vincula las incidencias con los problemas subyacentes y permite analizar la eficacia con la que la organización aborda las causas raíz para prevenir futuras incidencias.

Dónde obtenerlo

Esta información se almacena en la sección «Vínculos de incidencias» de una incidencia en Jira.

Ejemplos
PROB-123PROB-456Ninguno
Incumplimiento del SLA
SlaBreach
Indicador que señala si el tiempo de resolución de la incidencia superó el objetivo del SLA.
Descripción

Este atributo booleano calculado indica si una incidencia incumplió el SLA de «Tiempo de resolución». Su valor es verdadero si «IncidentResolutionCycleTime» es mayor que «TimeToResolutionTarget». Este indicador simplifica el análisis y la visualización, ya que permite filtrar y agregar datos fácilmente para calcular el KPI general de tasa de incumplimiento del SLA. Es la medida clave de resultados del Dashboard de seguimiento del rendimiento del SLA.

Por qué es importante

Ofrece un resultado claro y binario sobre el rendimiento del SLA, lo que facilita calcular las tasas de incumplimiento e identificar áreas problemáticas.

Dónde obtenerlo

Se calcula como («IncidentResolutionCycleTime» > «TimeToResolutionTarget»).

Ejemplos
truefalse
Número de traspasos
HandoffCount
Número de veces que la incidencia se reasignó a otro grupo o usuario.
Descripción

Esta métrica calculada cuenta cuántas veces cambiaron los campos «Assignee» o «AssignmentGroup» durante el ciclo de vida de la incidencia. Un número elevado de traspasos suele indicar ineficiencias en el proceso, una baja resolución en el primer contacto o falta de conocimientos, lo que prolonga los tiempos de resolución. Analizar este KPI ayuda a agilizar el proceso de asignación y mejorar la colaboración entre equipos.

Por qué es importante

Cuantifica las fricciones e ineficiencias del proceso causadas por las reasignaciones y ayuda a detectar oportunidades de mejora.

Dónde obtenerlo

Se calcula contando los cambios en los campos 'Assignee' o 'AssignmentGroup' del registro de cambios de la incidencia.

Ejemplos
015
Objetivo de tiempo de resolución
TimeToResolutionTarget
Duración objetivo del SLA para resolver la incidencia.
Descripción

Este atributo define el tiempo máximo previsto para resolver una incidencia de determinada prioridad o tipo. Es el valor de referencia con el que se compara el tiempo real de resolución para determinar el cumplimiento del SLA. Por lo general, este valor se establece de forma dinámica mediante reglas que tienen en cuenta factores como la prioridad, la gravedad o el tipo de incidencia. Es fundamental para cualquier Dashboard de seguimiento del rendimiento del SLA.

Por qué es importante

Proporciona el valor de referencia para medir el cumplimiento del SLA y sirve de base para el KPI de tasa de incumplimiento del SLA de incidencias.

Dónde obtenerlo

Se obtiene de la configuración del SLA en Jira Service Management. Es necesario identificar el objetivo específico, por ejemplo, «Tiempo de resolución».

Ejemplos
4 h8 h3 d
Persona que reportó la incidencia
Reporter
Usuario que creó o reportó inicialmente la incidencia.
Descripción

La persona que reportó la incidencia es quien la registró inicialmente, a menudo un usuario final u otro sistema. Analizar las incidencias por persona que las reportó puede ayudar a identificar a los usuarios o departamentos que tienen problemas con frecuencia. También permite comprender los patrones de comunicación, especialmente al analizar actividades como «En espera del cliente» y «Cliente respondió».

Por qué es importante

Ayuda a analizar el origen de las incidencias, detectar patrones relacionados con usuarios o departamentos concretos y comprender los retrasos en la comunicación con los clientes.

Dónde obtenerlo

El campo estándar «Persona que reportó» de una incidencia en Jira.

Ejemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
Resolución
Resolution
Resultado final o motivo por el que se resolvió la incidencia.
Descripción

El campo Resolución explica por qué una incidencia pasó a un estado resuelto. Entre los valores habituales se encuentran «Corregido», «Duplicado», «No se realizará» o «No se puede reproducir». Analizar la distribución de los tipos de resolución permite obtener información sobre la calidad de los reportes recibidos y la eficacia del proceso de resolución. Por ejemplo, un número elevado de resoluciones «Duplicado» puede indicar un problema en la creación o clasificación inicial de las incidencias.

Por qué es importante

Aporta contexto sobre el resultado de una incidencia, ayuda a clasificar las resoluciones y permite detectar tendencias en la forma de cerrar las incidencias.

Dónde obtenerlo

El campo estándar «Resolución» de una incidencia en Jira. Por lo general, se establece cuando la incidencia pasa a una categoría de estado «Completado».

Ejemplos
CompletadoCorregidoDuplicadoNo se corregirá
Tipo de incidencia
IssueType
Tipo de incidencia, como incidencia, solicitud de servicio o problema.
Descripción

Jira utiliza los tipos de incidencia para distinguir entre distintas clases de tareas. En la gestión de incidencias, el tipo principal es «Incidencia», aunque otros, como «Subtarea», también pueden ser pertinentes. Este atributo es fundamental para filtrar el conjunto de datos e incluir solo las incidencias, de modo que el análisis de Process Mining se centre en el proceso adecuado.

Por qué es importante

Permite delimitar correctamente el análisis a las incidencias y separarlas de otros tipos de trabajo, como las solicitudes de servicio o los cambios.

Dónde obtenerlo

El campo estándar «Tipo de incidencia» de una incidencia en Jira.

Ejemplos
IncidenciaSoporte de TIError de software
Tipo de solicitud del cliente
CustomerRequestType
Tipo específico de solicitud que el cliente envió a través del portal de servicio.
Descripción

Este campo clasifica las solicitudes desde la perspectiva del cliente, tal como aparecen en el portal de Jira Service Management (por ejemplo, «Reportar un problema del sistema»). Ofrece una clasificación fácil de entender para el usuario, que puede diferir del «Tipo de incidencia» interno. Analizar este atributo permite conocer cómo perciben y reportan los problemas los clientes, y ayuda a mejorar el diseño del portal y los servicios ofrecidos.

Por qué es importante

Ofrece una perspectiva de las categorías de incidencias centrada en el cliente, útil para analizar la demanda y mejorar su experiencia.

Dónde obtenerlo

El campo «Tipo de solicitud del cliente», específico de los proyectos de Jira Service Management.

Ejemplos
Obtener ayuda de TI > Reportar un problema del sistemaCorreo electrónico > Solicitud de acceso
Obligatorio Recomendado Opcional

Actividades de gestión de incidencias

Estos son los pasos y los hitos clave que conviene registrar en el registro de eventos para descubrir y analizar con precisión los flujos de trabajo de resolución de incidencias.
7 Recomendado 8 Opcional
Actividad Descripción
En espera de la persona usuaria
Marca el momento en que el equipo de soporte espera información o una acción de la persona usuaria. Se infiere a partir de un cambio de estado a uno específico de espera, como «En espera de la persona usuaria».
Por qué es importante

Aislar este tiempo «en espera» es fundamental para medir los SLA con precisión, ya que suele excluirse de los cálculos del tiempo de resolución. También ayuda a analizar las demoras en las respuestas de las personas usuarias.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. El evento corresponde a la fecha y hora en que el estado cambia a «En espera de la persona usuaria» o a un estado similar.

Capturar

Identifique la fecha y hora del cambio de estado a «En espera de la persona usuaria».

Tipo de evento inferred
Incidente cerrado
Representa el cierre administrativo definitivo del ticket del incidente una vez resuelto y verificado. Se infiere a partir del cambio de estado a «Cerrado».
Por qué es importante

Este es el evento final del proceso. Analizar el tiempo transcurrido entre «Resuelto» y «Cerrado» puede revelar demoras en las tareas administrativas de cierre o en la confirmación de la persona usuaria.

Dónde obtenerlo

Inferido a partir del historial de cambios de estado de la incidencia. El evento corresponde a la marca de tiempo en que el estado pasa a «Cerrado».

Capturar

Identifique la marca de tiempo del cambio de estado a «Cerrado».

Tipo de evento inferred
Incidente creado
Marca el inicio oficial del ciclo de vida del incidente: se envía un informe y se crea una incidencia en Jira. El sistema registra explícitamente este evento cuando se crea una incidencia nueva de tipo «Incidente».
Por qué es importante

Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta la resolución es fundamental para medir el tiempo total del ciclo y el cumplimiento de los SLA.

Dónde obtenerlo

Este evento explícito se obtiene de la fecha y hora de creación de la incidencia en Jira. El historial de la incidencia registra el evento de creación.

Capturar

Utilice la fecha y hora de creación de la incidencia.

Tipo de evento explicit
Incidente reasignado
Se produce cuando, después de la asignación inicial, el incidente se transfiere a otro agente o grupo. Se infiere a partir de cualquier cambio en el campo «Persona asignada» o «Grupo asignado».
Por qué es importante

El seguimiento de las reasignaciones es fundamental para analizar los traspasos. Un número elevado suele indicar ineficiencias en el proceso, falta de conocimientos o una asignación inicial incorrecta, lo que retrasa la resolución.

Dónde obtenerlo

Se infiere del historial de la incidencia al detectar cualquier actualización del campo «Persona asignada» después de que se haya completado por primera vez. Cada cambio constituye un evento de reasignación.

Capturar

Identifique los cambios posteriores en el campo «Persona asignada» después de la asignación inicial.

Tipo de evento inferred
Incidente resuelto
Esta actividad confirma que el incidente se ha resuelto correctamente y que el servicio se ha restablecido. A menudo coincide con el cambio al estado «Resuelto».
Por qué es importante

Este es el principal hito de éxito del proceso. El tiempo transcurrido hasta este punto es el KPI más habitual y representa el tiempo de resolución (TTR).

Dónde obtenerlo

Se infiere a partir del cambio de estado a «Resuelto». En muchos flujos de trabajo, este es el mismo evento que «Resolución propuesta» y representa el momento principal de resolución.

Capturar

Identifique la fecha y hora del cambio de estado a «Resuelto».

Tipo de evento inferred
Investigación iniciada
Indica que un agente asignado ha comenzado a diagnosticar activamente el incidente. Por lo general, se infiere cuando el estado de la incidencia cambia de «Abierto» o «Nuevo» a «En curso».
Por qué es importante

Este hito clave marca el inicio de las tareas activas de resolución. Medir el tiempo hasta esta actividad ayuda a identificar demoras iniciales en las colas y problemas de disponibilidad de recursos.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. La fecha y hora del evento corresponden al momento en que el estado pasa a indicar que el trabajo está en curso, por ejemplo, «En curso».

Capturar

Identifique la fecha y hora del cambio de estado a «En curso».

Tipo de evento inferred
Resolución propuesta
Esta actividad indica que se ha identificado e implementado una solución y que el incidente espera confirmación o validación final. Se infiere a partir del cambio de estado a «Resuelto».
Por qué es importante

Este hito importante marca el fin del trabajo activo del equipo de soporte. A menudo, es el evento que detiene el reloj del SLA.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. La fecha y hora del evento corresponden al momento en que el estado cambia a «Resuelto» o a un estado equivalente.

Capturar

Identifique la fecha y hora del cambio de estado a «Resuelto».

Tipo de evento inferred
Comentario añadido
Representa cualquier comunicación o anotación en la que un usuario añade un comentario al ticket del incidente. Es un evento explícito que se registra cada vez que se publica un comentario.
Por qué es importante

Analizar la frecuencia de los comentarios puede aportar información sobre los patrones de comunicación, la eficiencia de la colaboración y la complejidad de los incidentes. También permite detectar los incidentes que requieren demasiada comunicación.

Dónde obtenerlo

Este es un evento explícito. Jira guarda cada comentario con su fecha y hora y su autor, y permite consultarlo en el historial de comentarios de la incidencia o mediante la API.

Capturar

Utilice la fecha y hora de cada comentario añadido a la incidencia.

Tipo de evento explicit
Escalado a un equipo especializado
Indica que el incidente se ha escalado a un equipo especializado, por ejemplo, de nivel 2 o de desarrollo, para recibir soporte avanzado. Se infiere a partir de un cambio en el campo personalizado «Equipo de soporte» o de una reasignación específica.
Por qué es importante

Destaca los incidentes que requieren conocimientos especializados y permite seguir el flujo entre los distintos niveles de soporte. Esto ayuda a identificar cuellos de botella en los equipos especializados y analizar los patrones de escalamiento.

Dónde obtenerlo

Se infiere del historial de la incidencia mediante el seguimiento de los cambios en un campo personalizado que representa al equipo asignado o la identificación de un cambio en «Persona asignada» a un miembro de un grupo especializado conocido.

Capturar

Detecte un cambio en el campo personalizado «Equipo asignado» o cambios específicos en la persona asignada.

Tipo de evento inferred
Incidente asignado
Esta actividad indica la asignación inicial del incidente a un agente o grupo de soporte para que lo gestione. Se registra la primera vez que se completa el campo «Persona asignada» 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 los SLA. Ayuda a identificar demoras antes de que comience la investigación activa.

Dónde obtenerlo

Se infiere del historial de la incidencia al identificar el primer cambio en el campo «Persona asignada» cuyo valor anterior era «Sin asignar».

Capturar

Detecte la primera actualización del campo «Persona asignada» en el historial de la incidencia.

Tipo de evento inferred
Incidente priorizado
Representa la asignación de prioridad o gravedad al incidente, que determina su urgencia y su impacto en el negocio. Por lo general, se infiere a partir de la primera vez que se completan o actualizan los campos «Prioridad» o «Gravedad» después de crear la incidencia.
Por qué es importante

El seguimiento de la priorización permite analizar si los incidentes se evalúan de forma rápida y coherente. Las demoras en este paso pueden afectar directamente al cálculo de los SLA y a la asignación de recursos.

Dónde obtenerlo

Se infiere del historial de la incidencia, que registra los cambios en todos los campos. Busque la primera actualización de «Prioridad» o de un campo personalizado de «Gravedad» después de crear la incidencia.

Capturar

Detecte el primer cambio en el campo «Prioridad» del historial de la incidencia.

Tipo de evento inferred
Incidente reabierto
Representa la reactivación de un incidente resuelto porque el problema volvió a producirse o la solución no fue eficaz. Se infiere a partir de un cambio de estado de «Resuelto» o «Cerrado» a un estado abierto.
Por qué es importante

Los incidentes reabiertos miden directamente la calidad de la resolución y son un indicador clave del retrabajo. Analizar estos eventos ayuda a identificar cierres prematuros y soluciones ineficaces.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. El evento se registra cuando el estado pasa de uno terminal, como «Resuelto» o «Cerrado», a «Abierto» o «En curso».

Capturar

Detecte el cambio de estado de «Resuelto» o «Cerrado» a un estado abierto.

Tipo de evento inferred
La persona usuaria respondió
Indica que la persona usuaria ha proporcionado la información solicitada y que el incidente puede seguir avanzando. Se infiere cuando el estado deja de ser «En espera de la persona usuaria» y vuelve a uno activo.
Por qué es importante

Esta actividad marca el fin de una demora causada por la espera de la persona usuaria. Analizar el tiempo transcurrido entre «En espera de la persona usuaria» y este evento permite conocer el tiempo medio de respuesta.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. El evento se produce cuando el estado cambia de «En espera de la persona usuaria» a uno como «En curso», a menudo después de que la persona usuaria añada un comentario.

Capturar

Detecte el cambio de estado de «En espera de la persona usuaria» a «En curso».

Tipo de evento inferred
Solución temporal proporcionada
Representa la implementación de una solución temporal para restablecer el servicio mientras se desarrolla una solución permanente. Puede inferirse a partir de un cambio de estado o de un comentario específico.
Por qué es importante

Medir el tiempo que se tarda en proporcionar una solución temporal es un indicador clave de la rapidez con que se restablece el servicio. Permite distinguir entre una mitigación temporal y una resolución permanente.

Dónde obtenerlo

A menudo se infiere. Puede tratarse de un cambio al estado «Solución temporal proporcionada» o de la publicación de un comentario público que incluya palabras clave como «solución temporal».

Capturar

Identifique un cambio de estado específico o una palabra clave en un comentario.

Tipo de evento inferred
Vinculado a un ticket de problema
Se produce cuando un incidente se vincula a una incidencia de tipo «Problema» para analizar la causa raíz. Es un evento explícito que se registra cuando se crea un vínculo «se relaciona con» o «causado por» con una incidencia de tipo «Problema».
Por qué es importante

El seguimiento de este vínculo es esencial para comprender con qué eficacia la organización pasa de mitigar incidentes a analizar sus causas raíz y prevenirlos.

Dónde obtenerlo

Este es un evento explícito que se registra en el historial de vínculos de la incidencia. Cada vínculo creado tiene una fecha y hora, y puede filtrarse para mostrar los vínculos con incidencias de tipo «Problema».

Capturar

Utilice la fecha y hora de creación de un vínculo con una incidencia de tipo «Problema».

Tipo de evento explicit
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Jira Service Management

¿Todo listo para empezar?

Use este Template de datos para transformar la gestión de incidencias, detectar ineficiencias y reducir los tiempos de resolución. Empiece hoy mismo a optimizar el proceso.

Optimice la gestión de incidencias y resuélvalas más rápido

Reduzca el MTTR un 35 % y aumente la satisfacción de los usuarios con procesos más ágiles.

Comience la prueba gratuita

No se requiere tarjeta de crédito • Configuración en 5 minutos