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