Su Template de datos para la gestión de incidencias
Su Template de datos para la gestión de incidencias
- Atributos recomendados para recopilar
- Actividades clave que conviene seguir
- Instrucciones de extracción para Jira Service Management
Atributos de gestión de incidencias
| 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
|
|||
Actividades de gestión de incidencias
| 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
|
|||
Guías de extracción
¿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.
No se requiere tarjeta de crédito • Configuración en 5 minutos