Su Template de datos de gestión de incidentes

Jira Service Management
Su Template de datos de gestión de incidentes

Su Template de datos de gestión de incidentes

Esta plantilla ofrece un enfoque estructurado para recopilar los datos esenciales necesarios para analizar su proceso de gestión de incidentes. Detalla los atributos fundamentales que debe recopilar, las actividades clave que debe supervisar y proporciona orientación práctica para extraer esta información de su sistema de origen. Así dispondrá de todos los elementos necesarios para empezar a optimizar sus Workflow de resolución de incidentes.
  • Atributos recomendados para recopilar
  • Actividades clave que debe supervisar
  • Guía de extracción para Jira Service Management
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos de la gestión de incidentes

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para realizar un análisis completo de su proceso de gestión de incidentes.
5 Obligatorio 6 Recomendado 12 Opcional
Nombre Descripción
Actividad
ActivityName
El nombre del evento específico o del cambio de estado que se produjo en el incidente.
Descripción

La actividad representa un paso o evento diferenciado del ciclo de vida de la gestión de incidentes, como «Incident Created», «Incident Assigned» o «Resolution Proposed». Normalmente se obtiene de las transiciones de estado o de eventos de actualización específicos registrados en el historial o changelog de la incidencia de Jira. Analizar la secuencia y la duración de estas actividades es el objetivo principal de Process Mining, ya que permite revelar el flujo real del proceso, los cuellos de botella y las desviaciones.

Por qué es importante

Las actividades constituyen la base del mapa de procesos y permiten visualizar y analizar el ciclo de vida de los incidentes.

Dónde obtenerlo

Se obtiene del historial de la incidencia y de los datos del changelog de Jira, incluidos los cambios de estado y las actualizaciones de campos clave.

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

Este atributo registra la marca de tiempo de cada actividad del ciclo de vida del incidente. Es fundamental para calcular las duraciones, los tiempos de ciclo y los tiempos de espera entre los distintos pasos del proceso. Las marcas de tiempo precisas permiten realizar análisis detallados del rendimiento, supervisar el 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 derivan 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 de rendimiento.

Dónde obtenerlo

Esta es la fecha de «created» asociada a cada entrada del registro de cambios o historial de la incidencia de Jira.

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

El ID del incidente, denominado con frecuencia Issue Key en Jira, actúa como identificador único principal de cada incidente reportado. Vincula todas las actividades, comentarios y cambios de estado asociados desde el momento de su creación hasta el cierre final. En Process Mining, este ID es esencial para reconstruir el ciclo de vida completo de cada incidente y analizar de forma exhaustiva todo el proceso.

Por qué es importante

Es el identificador principal que permite correlacionar todos los eventos relacionados en un único caso, por lo que constituye la base de cualquier análisis de Process Mining.

Dónde obtenerlo

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

Ejemplos
INC-10234HELPDESK-5678OPS-9901
Sistema de origen
SourceSystem
El 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 en entornos donde se combinan datos de varios sistemas para obtener una visión integral del proceso. Especificar el sistema de origen garantiza la claridad del linaje de los datos y ayuda a diagnosticar problemas de calidad o extracción. En este modelo, el valor sería estático.

Por qué es importante

Proporciona un contexto esencial sobre el origen de los datos y garantiza la claridad y la trazabilidad, especialmente en análisis que abarcan varios sistemas.

Dónde obtenerlo

Este es un valor estático que debe añadirse durante el proceso de extracción de datos.

Ejemplos
Jira Service ManagementJira Cloud
Última actualización de datos
LastDataUpdate
La marca de tiempo que indica la última vez que se actualizaron los datos desde el sistema de origen.
Descripción

Este atributo registra cuándo se actualizó por última vez el conjunto de datos. Proporciona un contexto esencial para cualquier persona que analice el proceso, ya que garantiza que conozca la actualización de los datos. Esto es especialmente importante en los Dashboards de supervisión continua, donde la información actualizada resulta crucial para tomar decisiones oportunas. Normalmente, el valor es el mismo para todos los eventos de un único lote de extracción de datos.

Por qué es importante

Informa a los usuarios sobre la actualidad de los datos, un aspecto fundamental para garantizar la relevancia y precisión del análisis.

Dónde obtenerlo

Esta es la marca de tiempo de la ejecución de extracción de datos, añadida durante el proceso de transformación de datos.

Ejemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Estado
Status
La etapa actual del incidente dentro de su ciclo de vida.
Descripción

El campo de estado indica el estado actual de un incidente dentro del flujo de trabajo definido, como «Open», «In Progress», «Pending Customer» o «Resolved». Los cambios de estado son la fuente principal para generar el registro de actividades utilizado en Process Mining. Analizar el tiempo empleado en cada estado es fundamental para identificar cuellos de botella y comprender dónde pasan más tiempo los incidentes.

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 obtenerlo

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

Ejemplos
En cursoEsperando al clienteResueltoCerrado
Fecha de creación
CreatedDate
La fecha y hora en que se creó el incidente por primera vez en el sistema.
Descripción

Este atributo marca el inicio oficial del ciclo de vida del incidente. Es la marca de tiempo 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 de todo el caso en el análisis de Process Mining.

Por qué es importante

Sirve como punto de partida para todos los cálculos del tiempo de ciclo integral y las mediciones del SLA.

Dónde obtenerlo

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 se marcó como resuelto.
Descripción

Este atributo registra la marca de tiempo en que el incidente pasó por primera vez a un estado resuelto. Marca el final de la fase de trabajo activo y es el punto final para calcular el tiempo de resolución. Comparar la fecha de resolución con la fecha de creación proporciona la principal medida de 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 y permite calcular el tiempo total de ciclo y el rendimiento del SLA.

Dónde obtenerlo

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 al equipo asignado al incidente. Puede ser un nivel de soporte, como «L1 Helpdesk», un equipo especializado, como «Network Operations», o un equipo de desarrollo. Analizar las transiciones entre grupos de asignación es fundamental para comprender los escalamientos y las transferencias del proceso. Permite medir el rendimiento de los equipos, identificar cuellos de botella a nivel de equipo y analizar las dependencias entre equipos.

Por qué es importante

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

Dónde obtenerlo

A menudo se implementa como un campo personalizado en Jira, como «Team» o «Assignment Group». En algunos casos, puede derivarse de los componentes de Jira o de los roles del proyecto.

Ejemplos
Soporte de nivel 1Equipo de infraestructuraAdministradores de bases de datos
Prioridad
Priority
El nivel de prioridad asignado al incidente, que indica la urgencia de su resolución.
Descripción

La prioridad determina la rapidez necesaria para atender un incidente. A menudo combina el impacto y la urgencia, e influye directamente en los objetivos del SLA. Analizar los incidentes por prioridad ayuda a comprender si los incidentes de alta prioridad se gestionan más rápido que los de baja prioridad y si la priorización se aplica de forma coherente. Es una dimensión fundamental 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 asignan correctamente a los incidentes más críticos.

Dónde obtenerlo

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

Ejemplos
MáximaAltaMediaBaja
Responsable
Assignee
El usuario asignado actualmente para trabajar en el incidente.
Descripción

El responsable es el agente o usuario encargado del incidente en un momento determinado. Registrar los cambios de responsable es fundamental para analizar las transferencias, comprender la distribución de la carga de trabajo e identificar qué personas participan en pasos concretos del proceso. 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 realizar un seguimiento de la carga de trabajo individual, identificar cuellos de botella relacionados con agentes concretos y analizar el impacto de las transferencias en el tiempo de resolución.

Dónde obtenerlo

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

Ejemplos
John SmithEmily JonesServiceDeskAgent1
Categoría de la causa raíz
RootCauseCategory
La clasificación de la causa raíz subyacente del incidente.
Descripción

Este atributo registra el motivo fundamental por el que se produjo el incidente, como «Defecto de software», «Fallo de hardware» o «Error del usuario». Normalmente se completa después de la investigación y es esencial para una gestión eficaz de problemas y la prevención de futuros incidentes. Analizar las categorías de causas raíz ayuda a identificar debilidades sistémicas y priorizar las iniciativas de mejora. Un porcentaje elevado de causas raíz «Desconocidas» puede indicar la necesidad de 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 mediante la identificación y resolución de los orígenes de los incidentes.

Dónde obtenerlo

Casi siempre se trata de 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
El sistema, la aplicación o la parte de la infraestructura afectada por el incidente.
Descripción

Los componentes son subsecciones de un proyecto de Jira que se utilizan para agrupar incidencias en partes 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 son más propensas a presentar problemas. Esta información resulta valiosa para el análisis de causas raíz y puede 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 específica del sistema afectada, lo que ayuda a identificar los puntos críticos tecnológicos.

Dónde obtenerlo

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

Ejemplos
Servicio de autenticaciónDashboard de informesAplicación móvil
Es retrabajo
IsRework
Un indicador que señala si el incidente ha requerido retrabajo, por ejemplo, porque se volvió a abrir.
Descripción

Este atributo booleano calculado identifica los incidentes que han regresado a una etapa anterior del proceso, normalmente porque se reabrieron después de haberse resuelto. Los bucles 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 las razones por las que los incidentes no se resuelven correctamente a la primera.

Por qué es importante

Pone de manifiesto problemas de calidad e ineficiencias del proceso al señalar los incidentes que requieren trabajo repetido, y respalda 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
La medida del impacto del incidente en el negocio.
Descripción

La gravedad define el impacto que un incidente tiene en el negocio, desde la afectación a un solo usuario hasta una interrupción crítica del sistema. Mientras que la prioridad determina el orden de trabajo, la gravedad informa sobre el impacto general en el negocio. Analizar los incidentes por gravedad ayuda a comprender el rendimiento del proceso en los incidentes más importantes para el negocio y suele utilizarse junto con la prioridad para obtener un análisis más preciso.

Por qué es importante

Proporciona una visión del impacto en el negocio y permite centrar el análisis en los incidentes que más perjudican las operaciones.

Dónde obtenerlo

Normalmente es 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íticaImportanteMenorTrivial
ID del problema vinculado
LinkedProblemId
El identificador de un ticket de Problem vinculado a este incidente.
Descripción

Los incidentes que son síntomas de un problema subyacente de mayor alcance suelen vincularse a un ticket de Problem. Este campo almacena el ID de ese Problem asociado. Analizar estos vínculos ayuda a comprender la relación entre incidentes y problemas, medir la eficacia 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 y permite analizar la eficacia con la que la organización aborda las causas raíz para prevenir futuros incidentes.

Dónde obtenerlo

Esta información se almacena en la sección «Issue Links» de una incidencia de Jira.

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

Este atributo booleano calculado indica si un incidente incumplió su SLA de «Time to Resolution». Es verdadero cuando «IncidentResolutionCycleTime» es mayor que «TimeToResolutionTarget». Este indicador simplifica el análisis y la visualización, ya que permite filtrar y agregar los datos fácilmente para calcular el KPI general de SLA Breach Rate. Es la medida de resultado clave del Dashboard de seguimiento del rendimiento de los SLA.

Por qué es importante

Proporciona un resultado binario claro sobre el rendimiento del SLA, lo que facilita el cálculo de las tasas de incumplimiento y la identificación de las áreas problemáticas.

Dónde obtenerlo

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

Ejemplos
truefalse
Informador
Reporter
El usuario que creó o informó inicialmente del incidente.
Descripción

El informador es la persona, normalmente un usuario final u otro sistema, que registró primero el incidente. Analizar los incidentes por informador puede ayudar a identificar a los usuarios o departamentos que experimentan problemas con frecuencia. También puede utilizarse para comprender los patrones de comunicación, especialmente al analizar actividades como «Waiting for Customer» y «Customer Responded».

Por qué es importante

Ayuda a analizar las fuentes de los incidentes, identificar patrones relacionados con usuarios o departamentos concretos y comprender las demoras en la interacción con los clientes.

Dónde obtenerlo

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

Ejemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
Número de reasignaciones
HandoffCount
El número de veces que el incidente se reasignó a un grupo o usuario diferente.
Descripción

Esta métrica calculada cuenta cuántas veces cambiaron los campos «Assignee» o «AssignmentGroup» durante el ciclo de vida del incidente. Un número elevado de reasignaciones suele indicar ineficiencias del proceso, falta de resolución en el primer contacto o carencias de conocimiento, 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 la fricción y la ineficiencia del proceso causadas por las reasignaciones y ayuda a identificar oportunidades de mejora.

Dónde obtenerlo

Se calcula contando el número de cambios en el campo «Assignee» o «AssignmentGroup» del registro de cambios de la incidencia.

Ejemplos
015
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 previsto en el que debe resolverse un incidente 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. Normalmente, este valor se establece de forma dinámica según reglas que consideran factores como la prioridad, la gravedad o el tipo de incidencia. Es fundamental para cualquier Dashboard de seguimiento del rendimiento de los SLA.

Por qué es importante

Proporciona el valor de referencia para medir el cumplimiento del SLA y constituye la base del KPI Incident SLA Breach Rate.

Dónde obtenerlo

Se obtiene de la configuración de SLA de Jira Service Management. Es necesario identificar el objetivo específico, por ejemplo, «Time to resolution».

Ejemplos
4 h8 h3 días
Resolución
Resolution
El resultado final o el motivo por el que se resolvió el incidente.
Descripción

El campo de resolución explica por qué un incidente pasó a un estado resuelto. Entre las resoluciones habituales se incluyen «Fixed», «Duplicate», «Won't Do» o «Cannot Reproduce». Analizar la distribución de los tipos de resolución puede proporcionar información sobre la calidad de los informes recibidos y la eficacia del proceso de resolución. Por ejemplo, un número elevado de resoluciones «Duplicate» puede indicar un problema en la fase de creación o clasificación inicial del incidente.

Por qué es importante

Aporta contexto sobre el resultado de un incidente, ayuda a categorizar las resoluciones e identificar tendencias en la forma en que se cierran los incidentes.

Dónde obtenerlo

El campo estándar «Resolution» de una incidencia de Jira. Normalmente, este campo se establece cuando una incidencia pasa a una categoría de estado «Done».

Ejemplos
CompletadoCorregidoDuplicadoNo se corregirá
Tipo de incidencia
IssueType
El tipo de incidencia, como Incident, Service Request o Problem.
Descripción

Jira utiliza los tipos de incidencia para distinguir entre diferentes clases de tareas. En un contexto de gestión de incidentes, el tipo principal es «Incident», aunque otros, como «Sub-task», también pueden ser relevantes. Este atributo es fundamental para filtrar los datos e incluir únicamente los incidentes, de modo que el análisis de Process Mining se centre en el proceso correcto.

Por qué es importante

Garantiza que el análisis se limite correctamente a los incidentes y los separe de otros tipos de trabajo, como las solicitudes de servicio o los cambios.

Dónde obtenerlo

El campo estándar «Issue Type» de una incidencia de Jira.

Ejemplos
IncidenciaAyuda de TIError
Tipo de solicitud del cliente
CustomerRequestType
El tipo específico de solicitud que el cliente envía a través del portal de servicio.
Descripción

Este campo categoriza las solicitudes desde el punto de vista del cliente, tal como se presentan en el portal de Jira Service Management, por ejemplo, «Informar de un problema del sistema». Proporciona una clasificación de la incidencia fácil de entender para el usuario, que puede diferir del «Issue Type» interno. Analizar este atributo permite comprender mejor cómo perciben y notifican los problemas los clientes, y ayuda a mejorar el diseño del portal y la oferta de servicios.

Por qué es importante

Ofrece una visión de las categorías de incidentes centrada en el cliente, útil para analizar la demanda y mejorar la experiencia del cliente.

Dónde obtenerlo

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
Obligatorio Recomendado Opcional

Actividades de gestión de incidentes

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir y analizar con precisión sus Workflows de resolución de incidentes.
7 Recomendado 8 Opcional
Actividad Descripción
En espera del cliente
Marca el momento en que el equipo de soporte espera información o una acción por parte del cliente. Se infiere de una transición de estado a un estado de espera específico, como 'Waiting for customer'.
Por qué es importante

Aislar este tiempo de espera es fundamental para medir con precisión los SLA, ya que a menudo se excluye de los cálculos del tiempo de resolución. También ayuda a analizar los retrasos en las respuestas del cliente.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. El evento corresponde a la marca de tiempo en la que el estado cambia a 'Waiting for customer' o a un estado similar.

Recopilar

Identifique la marca de tiempo de la transición de estado a 'Waiting for customer'.

Tipo de evento inferred
Incidente cerrado
Representa el cierre administrativo final del ticket del incidente una vez resuelto y verificado. Se infiere a partir de la transición de estado a «Closed».
Por qué es importante

Este es el evento terminal del proceso. Analizar el tiempo entre «Resolved» y «Closed» puede revelar retrasos en las tareas administrativas de cierre o en los procesos de confirmación por parte del usuario.

Dónde obtenerlo

Se infiere a partir del historial de cambios de estado de la incidencia. El evento corresponde a la marca de tiempo en la que el estado pasa al estado final «Closed».

Recopilar

Identifique la marca de tiempo de la transición de estado a «Closed».

Tipo de evento inferred
Incidente creado
Marca el inicio oficial del ciclo de vida del incidente, cuando se envía un informe de incidente y se crea una incidencia nueva en Jira. Este evento se captura explícitamente cuando se registra en el sistema una incidencia nueva de tipo 'Incident'.
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 es un evento explícito capturado a partir de la marca de tiempo 'created' de la incidencia en Jira. El evento de creación de la incidencia queda registrado en su historial.

Recopilar

Utilice la marca de tiempo de creación de la incidencia.

Tipo de evento explicit
Incidente reasignado
Se produce cuando un incidente se transfiere de una persona agente o grupo a otro después de la asignación inicial. Este evento se infiere de cualquier cambio en el campo 'Assignee' o 'Assigned Group'.
Por qué es importante

El seguimiento de las reasignaciones es fundamental para analizar las transferencias. Un número elevado de reasignaciones suele indicar ineficiencias del proceso, carencias de conocimiento o un enrutamiento inicial incorrecto, lo que provoca retrasos en la resolución.

Dónde obtenerlo

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

Recopilar

Identifique los cambios posteriores en el campo 'Assignee' 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 correctamente y el servicio se ha restablecido. A menudo coincide con la transición al estado 'Resolved'.
Por qué es importante

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

Dónde obtenerlo

Se infiere del cambio de estado a 'Resolved'. En muchos Workflows, este es el mismo evento que 'Resolution Proposed' y representa el punto principal de resolución.

Recopilar

Identifique la marca de tiempo de la transición de estado a 'Resolved'.

Tipo de evento inferred
Investigación iniciada
Indica que una persona agente asignada ha comenzado a trabajar activamente en el diagnóstico del incidente. Normalmente se infiere cuando el estado de la incidencia cambia de 'Open' o 'New' a 'In Progress'.
Por qué es importante

Este hito clave marca el inicio de los esfuerzos activos de resolución. Medir el tiempo hasta esta actividad ayuda a identificar retrasos iniciales en la cola y problemas de disponibilidad de recursos.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. La marca de tiempo del evento corresponde al momento en que el estado cambia a uno que representa trabajo activo, como 'In Progress'.

Recopilar

Identifique la marca de tiempo de la transición de estado a 'In Progress'.

Tipo de evento inferred
Resolución propuesta
Esta actividad indica que se ha identificado e implementado una resolución y que el incidente está pendiente de confirmación o validación final. Se infiere de la transición de estado a 'Resolved'.
Por qué es importante

Este es un hito importante que señala el final del trabajo activo del equipo de soporte. A menudo es el evento que detiene el contador del SLA.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. La marca de tiempo del evento corresponde al momento en que el estado cambia a 'Resolved' o a un estado equivalente.

Recopilar

Identifique la marca de tiempo de la transición de estado a 'Resolved'.

Tipo de evento inferred
Cliente respondió
Indica que el cliente ha proporcionado la información solicitada y que el incidente puede continuar. Se infiere cuando el estado deja de ser 'Waiting for customer' y vuelve a un estado activo.
Por qué es importante

Esta actividad marca el final de un retraso provocado por el cliente. Analizar la duración entre 'Waiting For Customer' y este evento revela el tiempo medio de respuesta del cliente.

Dónde obtenerlo

Se infiere del historial de cambios de estado de la incidencia. El evento se produce cuando el estado cambia de 'Waiting for customer' a un estado como 'In Progress', a menudo después de que el cliente añada un comentario.

Recopilar

Detecte el cambio de estado de 'Waiting for customer' a 'In Progress'.

Tipo de evento inferred
Comentario añadido
Representa cualquier evento de comunicación o toma de notas en el que una persona usuaria añade un comentario al ticket del incidente. Es un evento explícito que se captura cada vez que se publica un comentario.
Por qué es importante

Analizar la frecuencia de los comentarios puede proporcionar información sobre los patrones de comunicación, la eficiencia de la colaboración y la complejidad de un incidente. También puede poner de manifiesto los incidentes que requieren una comunicación excesiva.

Dónde obtenerlo

Este es un evento explícito. Jira almacena cada comentario con su marca de tiempo y autor, disponibles en el historial de comentarios de la incidencia o mediante la API.

Recopilar

Utilice la marca de tiempo de cada comentario añadido a la incidencia.

Tipo de evento explicit
Escalado al equipo especialista
Indica que el incidente se ha escalado a un equipo especializado, por ejemplo, Tier 2 o Desarrollo, para recibir soporte avanzado. Se infiere de un cambio en un campo personalizado 'Support Team' o de una reasignación específica.
Por qué es importante

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

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 de 'Assignee' a una persona miembro de un grupo especialista conocido.

Recopilar

Detecte un cambio en un campo personalizado de 'Assigned Team' o cambios específicos de la persona asignada.

Tipo de evento inferred
Incidente asignado
Esta actividad indica la asignación inicial del incidente a una persona agente de soporte o a un grupo para su gestión. Se captura mediante el seguimiento de la primera vez que se completa el campo 'Assignee' o 'Assigned Group'.
Por qué es importante

Mide el tiempo de respuesta y asignación inicial, un componente clave de las métricas de los SLA. Ayuda a identificar retrasos 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 'Assignee' cuyo valor anterior era 'Unassigned'.

Recopilar

Detecte la primera actualización del campo 'Assignee' en el historial de la incidencia.

Tipo de evento inferred
Incidente priorizado
Representa la asignación de la prioridad o la gravedad del incidente, que determina su urgencia y su impacto empresarial. Normalmente se infiere a partir de la primera vez que los campos 'Priority' o 'Severity' se completan 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 coherente. Los retrasos en este paso pueden afectar directamente a los cálculos de los SLA y a la asignación de recursos.

Dónde obtenerlo

Se infiere del Registro de eventos de la incidencia, que registra los cambios realizados en todos los campos. Busque la primera actualización del campo 'Priority' o de un campo personalizado 'Severity' después del evento de creación de la incidencia.

Recopilar

Detecte el primer cambio en el campo 'Priority' del Registro de eventos de la incidencia.

Tipo de evento inferred
Incidente reabierto
Representa una situación en la que un incidente resuelto anteriormente se reactiva porque el problema volvió a producirse o la solución no fue eficaz. Se infiere de un cambio de estado de 'Resolved' o 'Closed' 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 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 un estado terminal, como 'Resolved' o 'Closed', a 'Open' o 'In Progress'.

Recopilar

Detecte el cambio de estado de 'Resolved' o 'Closed' a un estado abierto.

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 de un cambio de estado o de un comentario específico.
Por qué es importante

Medir el tiempo necesario para proporcionar una solución temporal es un indicador clave de la velocidad de restablecimiento del servicio. Ayuda a diferenciar entre una mitigación temporal y una resolución permanente.

Dónde obtenerlo

A menudo se infiere. Puede tratarse de una transición al estado 'Workaround Provided' o de la adición de un comentario público que contenga palabras clave específicas, como 'workaround'.

Recopilar

Identifique una transición de estado específica 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 'Problem' para realizar un análisis de la causa raíz. Es un evento explícito que se captura cuando se crea un vínculo 'relates to' o 'caused by' con una incidencia de tipo Problem.
Por qué es importante

El seguimiento de este vínculo es esencial para comprender la eficacia con la que la organización pasa de mitigar el incidente a analizar y prevenir la causa raíz.

Dónde obtenerlo

Este es un evento explícito registrado en el historial de vínculos de la incidencia. Cada creación de vínculo tiene una marca de tiempo y puede filtrarse para mostrar los vínculos con incidencias de tipo 'Problem'.

Recopilar

Utilice la marca de tiempo de creación de un vínculo de incidencia con una incidencia de tipo 'Problem'.

Tipo de evento explicit
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Jira Service Management

¿Listo para empezar?

Aproveche esta plantilla de datos para transformar su gestión de incidentes, detectar ineficiencias y lograr tiempos de resolución más cortos. Empiece a optimizar su proceso hoy mismo.

Optimice la gestión de incidentes y resuélvalos más rápido

Reduzca el MTTR un 35 % y aumente la satisfacción de los usuarios con procesos optimizados.

Iniciar la prueba gratuita

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