> Mejora Continua de Procesos > Gestión de Problemas > Jira Service Management > Plantilla de Datos

Su Plantilla de Datos para la Gestión de Problemas

Jira Service Management

Atributos de Gestión de Problemas (21) Actividades de Gestión de Problemas (14) Guías de Extracción (2)

Su Plantilla de Datos para la Gestión de Problemas

Esta plantilla sirve como una hoja de ruta completa para analizar sus flujos de trabajo de gestión de servicios de TI, identificando los puntos de datos esenciales y los hitos del proceso dentro de Jira Service Management. Proporciona una visión estructurada de los atributos y actividades necesarios para obtener una visibilidad completa de cómo su equipo maneja los problemas subyacentes y el análisis de causa raíz. Utilice estas directrices para optimizar su recopilación de datos y asegurar que sus iniciativas de Process Mining generen insights accionables.

Atributos recomendados para un análisis profundo
Hitos del proceso para capturar en su registro de eventos
Guía técnica para la extracción de datos

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de Gestión de Problemas

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis exhaustivo del ciclo de vida de su gestión de problemas.

5 Requerido 5 Recomendado 11 Opcional

	Nombre	Descripción
	Actividad ActivityName	La acción específica o el cambio de estado que ocurrió para el registro de problema.
Descripción Este atributo captura el nombre del evento o la transición de estado que ocurre dentro del ciclo de vida de la gestión de problemas. Ejemplos incluyen 'Problema Registrado', 'Estado Cambiado a Investigación' o 'Causa Raíz Identificada'. Es esencial para mapear el flujo del proceso e identificar la secuencia de pasos tomados para resolver un problema. En Process Mining, estas actividades forman los nodos del mapa de proceso. Por qué es importante Define los pasos en el mapa de procesos y permite el análisis de variantes de proceso. Dónde obtener Changelog (Historial) de Jira o transiciones de estado del problema Ejemplos Registro de Problema CreadoInvestigación IniciadaCausa Raíz IdentificadaSolución Temporal ActualizadaRegistro de Problema Cerrado
	Registro de Problema ProblemKey	El identificador único asignado al registro de problema en Jira Service Management.
Descripción Este atributo sirve como identificador central del caso para el análisis de Process Mining. Representa la clave única (por ejemplo, PM-1001) generada por Jira Service Management cuando se crea un nuevo registro de problema. Se utiliza para agrupar todas las actividades, cambios de estado y actualizaciones relacionadas en una única instancia de proceso de principio a fin. Analizar este atributo permite la visualización del ciclo de vida completo de un problema, desde la detección inicial hasta la investigación y el cierre final. Por qué es importante Es la clave fundamental necesaria para reconstruir el flujo de proceso y rastrear registros de problemas específicos. Dónde obtener Tabla de problemas, campo 'Clave' o 'Clave del Problema' Ejemplos PM-1023PM-4099PRB-3321PM-5001
	Source System SourceSystem	El nombre del sistema donde se originaron los datos.
Descripción Identifica el sistema de software del cual se extrajeron los datos del proceso. En este contexto, el valor es consistentemente 'Jira Service Management'. Este atributo es particularmente útil en entornos multisistema para distinguir fuentes de datos, aunque para esta vista específica, sirve principalmente como un identificador estático para la procedencia de los datos. Por qué es importante Proporciona contexto sobre el origen de los datos, especialmente al fusionar con otros datos de Gestión de Servicios de TI. Dónde obtener Configuración Codificada o del Sistema Ejemplos Jira Service ManagementJira CloudJSM-Prod
	Timestamp EventTimestamp	La fecha y hora exactas en que ocurrió la actividad.
Descripción Este atributo registra el momento preciso en que ocurrió una actividad. Se utiliza para secuenciar eventos cronológicamente y calcular duraciones entre pasos. Las marcas de tiempo precisas son críticas para calcular los tiempos de ciclo, como el tiempo desde 'Problema Registrado' hasta 'Causa Raíz Identificada', y para analizar el rendimiento a lo largo del tiempo. Por qué es importante Permite el cálculo de todos los KPI basados en el tiempo y el ordenamiento correcto de los eventos. Dónde obtener Fecha de creación del Changelog de Jira o fecha de creación del problema Ejemplos 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Última actualización de datos LastDataUpdate	La marca de tiempo cuando los datos fueron extraídos o actualizados por última vez.
Descripción Indica cuándo el conjunto de datos fue sincronizado por última vez con el entorno de Jira Service Management en vivo. Esto asegura que los analistas comprendan la frescura de los datos. Se utiliza para validar que el análisis refleja el estado más actual del proceso y para identificar posibles problemas de latencia de datos. Por qué es importante Asegura la frescura de los datos y ayuda a confiar en los resultados del análisis. Dónde obtener ETL Timestamp Ejemplos 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Categoría de Causa Raíz RootCauseCategory	La clasificación de la causa subyacente del problema.
Descripción Categoriza la falla técnica o de proceso que causó el problema, como 'Error de Software', 'Error Humano' o 'Fallo de Hardware'. Este es a menudo un campo personalizado en Jira Service Management. Este atributo apoya el dashboard de 'Distribución de Categorías de Causa Raíz', permitiendo decisiones estratégicas sobre dónde invertir en infraestructura o capacitación para prevenir recurrencias. Por qué es importante Clave para identificar problemas sistémicos y guiar medidas preventivas. Dónde obtener Campo personalizado 'Causa Raíz' o 'Categoría de Causa Raíz' Ejemplos Error de Software`Error de Configuración`Problema de CapacidadProblema del Proveedor
	Grupo de Soporte Asignado SupportGroup	El equipo técnico o grupo actualmente asignado para investigar el problema.
Descripción Identifica al equipo específico responsable del registro de problemas en el momento del evento. En Jira Service Management, esto a menudo se mapea a 'Componente' o un campo personalizado como 'Grupo de Soporte'. Este atributo es vital para el dashboard de 'Cuellos de Botella en Traspasos entre Grupos de Soporte', permitiendo a los analistas visualizar cómo los problemas se mueven entre equipos y dónde permanecen por más tiempo. Por qué es importante Esencial para la minería organizacional e identificar la fricción entre equipos. Dónde obtener Campo de problema 'Componente' o campo personalizado 'Grupo de Soporte' Ejemplos Administración de Bases de `datos`Operaciones de RedSoporte de Aplicaciones Nivel 2
	Prioridad Priority	El nivel de criticidad asignado al registro de problema.
Descripción Indica la urgencia y el impacto del problema, típicamente desde 'Bajo' hasta 'Crítico'. Este campo se utiliza para segmentar el análisis y asegurar que los problemas de alta prioridad se resuelvan dentro de los objetivos del SLA. Analizar este atributo ayuda en el dashboard de 'Cumplimiento de SLA y Tendencias de Objetivos' a verificar si los riesgos críticos del negocio se priorizan correctamente. Por qué es importante Permite la segmentación del rendimiento del proceso por criticidad empresarial. Dónde obtener Campo de problema 'Prioridad' Ejemplos Más AltaAltoMedioBajo
	Resumen del Problema ProblemSummary	La descripción de texto breve o el título del registro de problema.
Descripción Contiene el resumen principal del registro de problemas. Aunque se basa principalmente en texto, proporciona contexto para los analistas que revisan casos individuales dentro de la herramienta de Process mining. Permite la búsqueda por palabras clave y el análisis cualitativo de los tipos de problemas que se registran. Por qué es importante Proporciona un contexto legible para el identificador del caso. Dónde obtener Campo de problema 'Resumen' Ejemplos Tiempo de espera de conexión a la base de datos en la región EUPico de latencia del servicio de correo electrónicoCola de procesamiento de pedidos atascada
	Usuario UserKey	El identificador único o el nombre del usuario que realizó la actividad.
Descripción Captura la identidad de la persona o cuenta de sistema responsable de ejecutar la actividad específica. Esto podría ser el 'Asignatario' que actualiza el registro o el 'Autor' de un cambio de estado. Estos datos se utilizan para analizar la utilización de recursos, identificar cuellos de botella en los traspasos entre usuarios y asegurar la rendición de cuentas dentro del proceso de gestión de problemas. Por qué es importante Crítico para analizar traspasos, segregación de funciones y carga de trabajo de recursos. Dónde obtener Campo 'autor' de Jira en el changelog o campo 'asignatario' en el problema Ejemplos j.smithautomatización_del_sistemam.doe
	¿Se reabrió? IsReopened	Bandera que indica si el problema fue reabierto después del cierre.
Descripción Una bandera booleana que se establece en verdadero si el registro de problemas transicionó de un estado cerrado a un estado abierto. Esto apoya el 'Análisis de la Tasa de Reapertura de Problemas'. Las altas tasas de reapertura indican problemas de calidad con las soluciones permanentes o procedimientos de verificación insuficientes. Por qué es importante Indicador de calidad para la efectividad de las soluciones. Dónde obtener Derivado de transiciones de estado Ejemplos truefalse
	Código de Resolución ResolutionCode	El código que indica cómo se resolvió el problema.
Descripción Especifica el resultado final del registro de problema, como 'Resuelto', 'No se reparará', 'Duplicado' o 'No se puede reproducir'. Se utiliza para filtrar los problemas resueltos con éxito de aquellos cerrados por razones administrativas, asegurando que los cálculos de KPI como 'Tiempo medio hasta la causa raíz' sean precisos. Por qué es importante Distingue entre soluciones efectivas y cierres administrativos. Dónde obtener Campo de problema 'Resolución' Ejemplos HechoNo se realizará`Duplicado`No se Puede Reproducir
	Duración de la Investigación InvestigationDuration	Tiempo transcurrido desde el registro del problema hasta la identificación de la causa raíz.
Descripción Calcula la duración entre la creación del registro de problemas y la marca de tiempo de la actividad 'Causa Raíz Identificada'. Esta es la métrica principal para el dashboard de 'Análisis del Tiempo de Ciclo de Investigación'. Ayuda a los gerentes a identificar problemas complejos que estancaron al equipo o la falta de recursos en la fase de diagnóstico. Por qué es importante Métrica principal para la eficiencia de la fase de análisis de causa raíz. Dónde obtener Calculado a partir de marcas de tiempo de eventos Ejemplos 48 horas5 días30 minutos
	Estado de Incumplimiento de SLA SlaBreachStatus	Indica si el registro de problemas ha incumplido su acuerdo de nivel de servicio.
Descripción Un campo booleano o de estado que indica si el tiempo de resolución ha excedido el objetivo acordado. Esto ayuda en el dashboard de 'Cumplimiento de SLA y Tendencias de Objetivos'. Destaca casos que exponen a la organización a riesgos de cumplimiento o penalizaciones. Por qué es importante Crítico para el monitoreo de cumplimiento y rendimiento. Dónde obtener Lógica del campo SLA de Jira Service Management Ejemplos CumplidoIncumplidoPausado
	Fecha de Creación CreatedDate	La fecha en que se creó el registro de problema.
Descripción La marca de tiempo cuando el problema se registró por primera vez en el sistema. Si bien la marca de tiempo del evento maneja la temporización de la actividad, este atributo específico a menudo se utiliza para filtrado de alto nivel (por ejemplo, 'Mostrarme todos los problemas creados en el Q1'). Sirve como punto de anclaje para el análisis de antigüedad. Por qué es importante Fecha de anclaje para el análisis de antigüedad y volumen de entrada. Dónde obtener Campo de problema 'Creado' Ejemplos 2023-01-012023-06-15
	Fuente de Detección DetectionSource	Cómo se identificó el problema (ej., Proactivo, Reactivo).
Descripción Indica el origen de la identificación del problema. Los valores comunes incluyen 'Monitoreo Proactivo', 'Incidente de Mesa de Servicio' o 'Notificación de Proveedor'. Este atributo se utiliza en el dashboard de 'Identificación Proactiva vs Reactiva' para medir la madurez del proceso de gestión de problemas. Por qué es importante Mide la madurez del proceso y la efectividad de los sistemas de monitoreo. Dónde obtener Campo personalizado 'Fuente' o 'Fuente de Detección' Ejemplos Monitoreo ProactivoEscalada de IncidentesNotificación a Proveedor
	Recuento de Incidentes Vinculados LinkedIncidentCount	El número de incidentes vinculados a este registro de problema.
Descripción Un recuento de tickets de incidente asociados con el registro de problemas. Este atributo cuantifica el impacto del problema en la base de usuarios. Se utiliza en el KPI de 'Profundidad de Vinculación Incidente-Problema' para priorizar problemas que están generando el mayor volumen de tickets de soporte. Por qué es importante Cuantifica el impacto comercial basándose en el volumen de incidentes. Dónde obtener Recuento de enlaces en la tabla 'issuelinks' donde el tipo es 'Problema/Incidente' Ejemplos 011550
	Reportador ReporterName	El usuario que originalmente registró el problema.
Descripción Identifica al individuo que creó el registro de problemas. Esto es distinto del asignado. Analizar a los reportantes ayuda a entender dónde se están detectando los problemas (ej., Agentes de Servicio de Atención al Cliente vs. Administradores de Sistema). Esto añade contexto al análisis 'Proactivo vs Reactivo'. Por qué es importante Identifica la fuente de entrada de problemas. Dónde obtener Campo de problema 'Reportante' Ejemplos monitoring_servicehelpdesk_leadnetwork_admin
	Revisión Post-Implementación Realizada ReviewStatus	Indica si se realizó una Revisión Post-Implementación (PIR).
Descripción Rastrea si la actividad o el indicador de 'Revisión Post-Implementación' está presente en el caso. Esto es esencial para el dashboard de 'Cumplimiento de Revisión Post-Implementación'. Asegura que la organización cumpla con los requisitos de gobernanza para la mejora continua. Por qué es importante Métrica de cumplimiento para el aprendizaje organizacional. Dónde obtener Campo personalizado 'Estado PIR' o existencia de actividad 'PIR' Ejemplos CompletadoPendienteNo Requerido
	Solicitud de Cambio Vinculada LinkedChangeRequest	El identificador de la solicitud de cambio vinculada a este problema.
Descripción Almacena el ID de la Solicitud de Cambio (RFC) creada para implementar la solución permanente. Este enlace es vital para el dashboard 'Retraso en el inicio de la solicitud de cambio'. Conecta el proceso de Gestión de Problemas con la Gestión de Cambios, permitiendo un análisis entre procesos. Por qué es importante Conecta la investigación con la remediación en el proceso de Gestión de Cambios. Dónde obtener Enlaces de problema donde el tipo es 'resuelto por' o similar Ejemplos CR-404CHG-1099CR-5512
	Solución Temporal Disponible WorkaroundDetails	Indica si se ha documentado una solución provisional para el problema.
Descripción Captura si existe o se ha publicado un texto de solución provisional. Esto permite a la organización rastrear la 'Velocidad de Publicación de Soluciones Provisionales'. El análisis de este campo ayuda a determinar qué tan rápido el equipo puede restaurar la estabilidad del servicio incluso antes de encontrar una solución permanente. Por qué es importante Clave para medir la velocidad de la ayuda provisional proporcionada al negocio. Dónde obtener Campo personalizado 'Solución Provisional' Ejemplos Reiniciar el servicioBorrar caché del navegadorNinguno proporcionado

Requerido Recomendado Opcional

Actividades de Gestión de Problemas

Estos son los pasos y hitos clave del proceso para capturar en su registro de eventos y lograr un descubrimiento preciso de sus flujos de trabajo de resolución.

8 Recomendado 6 Opcional

	Actividad	Descripción
	Asignado a Grupo de Soporte	La asignación del registro de problema a un equipo técnico o grupo de soporte específico. Esto se rastrea a través de cambios en el campo personalizado 'Grupo de Soporte' o en el campo 'Asignado' si no se utilizan grupos.
Por qué es importante Crítico para analizar traspasos y cuellos de botella entre equipos. Las altas tasas de transferencia pueden indicar ineficiencias en el enrutamiento. Dónde obtener Historial de problemas de Jira: Campo 'Grupo de Soporte' o 'Asignatario' cambió Capturar Registrado cuando el campo de asignación cambia Tipo de evento explicit
	Causa Raíz Identificada	El punto donde la causa subyacente se registra formalmente. Esto se infiere de un cambio de estado a 'Causa Raíz Identificada' o de la cumplimentación del campo 'Causa Raíz'.
Por qué es importante Un hito importante que finaliza la fase de investigación. Esencial para calcular el 'Tiempo Promedio para el Descubrimiento de la Causa Raíz'. Dónde obtener Historial de problemas de Jira: Estado cambió a 'Causa Raíz Identificada' O Campo 'Causa Raíz' poblado Capturar Comparar campo de estado o verificar población de campo Tipo de evento inferred
	Incidente Vinculado a Problema	La acción de vincular un ticket de Incidente relacionado al registro de Problema. Esto se captura en la tabla de enlaces de incidencias o en el historial.
Por qué es importante Determina el impacto y el alcance del problema. Esencial para el KPI de 'Profundidad de Vinculación Incidente-Problema' y para priorizar según el impacto en el negocio. Dónde obtener Enlaces de problemas de Jira: Enlace creado con tipo 'causa' o 'se relaciona con' Capturar Registrado cuando se crea un enlace de problema Tipo de evento explicit
	Investigación Iniciada	La transición del estado del problema a un estado de investigación activa (por ejemplo, 'Bajo Investigación' o 'En Curso'). Esto marca el comienzo de la fase de trabajo activo.
Por qué es importante Inicia el cronómetro para el tiempo de ciclo de la investigación. Ayuda a distinguir entre el tiempo de espera en la cartera de pendientes y el análisis activo real. Dónde obtener Historial de problemas de Jira: Estado cambió a 'En Investigación' o 'En Progreso' Capturar Comparar actualizaciones de campo de estado Tipo de evento inferred
	Registro de Problema Cerrado	La terminación final del ciclo de vida del problema. Capturada explícitamente cuando el estado cambia a 'Cerrado'.
Por qué es importante El final definitivo de la instancia del proceso. Necesario para calcular el tiempo de ciclo total y las tasas de cierre. Dónde obtener Historial de problemas de Jira: Estado cambió a 'Cerrado' Capturar Registrado cuando el estado transiciona a Cerrado Tipo de evento explicit
	Registro de Problema Creado	El evento inicial donde se crea el ticket de Problema en el sistema. Esto se captura explícitamente en el historial de la incidencia como la marca de tiempo de creación.
Por qué es importante Marca el inicio del ciclo de vida de la gestión de problemas y permite el análisis de volumen. Esencial para calcular el rendimiento y las tasas de entrada. Dónde obtener Tabla de problemas de Jira: Marca de tiempo de Fecha de Creación o Pestaña Historial: Evento Problema Creado Capturar Registrado cuando la transacción de creación del problema es confirmada Tipo de evento explicit
	Resolución Verificada	La confirmación de que la solución resolvió eficazmente el problema. Se infiere de una transición de estado a 'Resuelto' o a un estado específico de 'Verificado'.
Por qué es importante Puerta de calidad que asegura que la solución funciona. Los retrasos aquí indican cuellos de botella en las pruebas o en la aceptación del usuario. Dónde obtener Historial de problemas de Jira: Estado cambió a 'Resuelto' o 'Verificado' Capturar Comparar actualizaciones de campo de estado Tipo de evento inferred
	Solución Temporal Actualizada	La cumplimentación o actualización del campo de texto 'Solución Temporal'. Este evento indica que se ha documentado una solución provisional.
Por qué es importante Mide la velocidad de proporcionar ayuda al negocio. Crítico para el KPI de 'Tiempo de Espera de Disponibilidad de Soluciones Provisionales'. Dónde obtener Historial de problemas de Jira: Campo 'Solución Provisional' cambió (no nulo) Capturar Registrado cuando el campo Solución Provisional es modificado Tipo de evento explicit
	Prioridad del Problema Cambiada	Una actualización del campo Prioridad del registro de problemas. Esto se captura monitoreando la pestaña de historial para detectar cambios en el campo 'Prioridad'.
Por qué es importante Indica la escalada o desescalada del problema. Analizar esto ayuda a identificar la precisión inicial del triaje y el envejecimiento de la acumulación de alta prioridad. Dónde obtener Historial de problemas de Jira: Campo 'Prioridad' cambió de Valor Antiguo a Nuevo Valor Capturar Registrado cuando el campo Prioridad es actualizado Tipo de evento explicit
	Problema Reabierto	La transición de un problema de un estado 'Resuelto' o 'Cerrado' de nuevo a un estado activo. Indica una solución fallida o una resolución rechazada.
Por qué es importante Una métrica de calidad principal. Las altas tasas de reapertura indican un análisis de causa raíz o pruebas ineficaces. Dónde obtener Historial de problemas de Jira: Estado cambió de 'Cerrado'/'Resuelto' a 'Abierto'/'En Progreso' Capturar Comparar secuencia de campo de estado Tipo de evento inferred
	Revisión Post-Implementación	La ejecución de una revisión después de aplicar la solución. Capturada a través de un cambio de estado a 'En Revisión' o actualizaciones de campos específicos de la Revisión Post-Implementación (PIR).
Por qué es importante Actividad de cumplimiento que asegura la captura de lecciones aprendidas. Apoya el análisis de 'Cumplimiento de Revisión Post-Implementación'. Dónde obtener Historial de problemas de Jira: Estado cambió a 'En Revisión' O Campo 'Notas PIR' actualizado Capturar Comparar campo de estado o actualizaciones de campo PIR Tipo de evento inferred
	SLA Incumplido	Un evento que indica que el tiempo de resolución del problema excedió el Acuerdo de Nivel de Servicio definido. Esto se calcula comparando la fecha objetivo del SLA con la fecha de resolución.
Por qué es importante Crítico para la presentación de informes de cumplimiento. Ayuda a identificar qué prioridades o categorías con mayor frecuencia no cumplen los objetivos. Dónde obtener Registros SLA de Jira Service Management: 'Tiempo hasta la Resolución' > Objetivo, o calculado Capturar Derivar de los datos del campo SLA o comparar la Fecha de Vencimiento con la Fecha de Resolución Tipo de evento calculated
	Solicitud de Cambio Vinculada	La vinculación de una Solicitud de Cambio (RFC) al registro de Problema. Esto indica el inicio del proceso de solución permanente.
Por qué es importante Mide el retraso entre la identificación de la causa y el inicio de la remediación. Apoya el KPI de 'Retraso en la Transición de Gestión de Cambios'. Dónde obtener Enlaces de problemas de Jira: Enlace creado con tipo 'resuelto por' o que enlaza a tipo de problema 'Cambio' Capturar Registrado cuando se crea un enlace a un tipo de problema de Cambio Tipo de evento explicit
	Solución Permanente Aplicada	La transición que indica que la solución ha sido implementada. Esto se infiere usualmente de un cambio de estado a 'Implementando' o 'Resuelto'.
Por qué es importante Marca el final del trabajo de remediación técnica. Se utiliza para medir el tiempo de ciclo de implementación. Dónde obtener Historial de problemas de Jira: Estado cambió a 'Implementado', 'Pendiente de Verificación' o 'Corregido' Capturar Comparar actualizaciones de campo de estado Tipo de evento inferred

Recomendado Opcional

Guías de Extracción

Cómo obtener sus `datos` de `Jira Service Management`

Pasos

Inicie sesión en su instancia de Jira Service Management usando un navegador web con una cuenta que tenga permisos de 'Examinar Proyectos' para el proyecto de Gestión de Problemas.
Navegue a la barra de menú superior y seleccione Filtros, luego haga clic en Búsqueda Avanzada de Problemas para abrir el Navegador de Problemas.
Cambie el modo de búsqueda a JQL (Lenguaje de Consulta de Jira) en lugar de Básico si aún no está seleccionado.
Ingrese la cadena de consulta JQL específica proporcionada en la sección de Consulta a continuación para aislar los registros de Problema (ej., project = 'Gestión de Problemas'). Asegúrese de que el rango de tiempo sea apropiado para los límites de exportación del sistema.
Haga clic en el botón Buscar para verificar que la lista de problemas devuelva los registros de Problema esperados.
Localice el botón Exportar en la esquina superior derecha de la interfaz del navegador de problemas.
Seleccione Exportar XML del menú desplegable. No seleccione CSV, ya que la exportación estándar de CSV solo proporciona datos del estado actual y carece de los registros de cambios históricos necesarios para Process mining.
Guarde el archivo XML generado (ej., jira_export.xml) en un directorio local accesible por su entorno de procesamiento.
Prepare el entorno de Python instalando la librería pandas requerida si aún no está presente.
Ejecute el script de Python proporcionado en la sección de Consulta, asegurándose de que la variable de ruta del archivo coincida con la ubicación de su archivo XML guardado.
El script analiza la estructura RSS/XML, extrayendo la marca de tiempo de 'Creación', las entradas de 'Historial' para los cambios de estado/prioridad/asignación, y los 'Enlaces de Problemas' para los incidentes relacionados.
El script calcula los incumplimientos de SLA comparando las fechas de resolución con las fechas de vencimiento y genera un registro de eventos CSV formateado listo para ProcessMind.

Configuración

Formato de Exportación: Debe usar la exportación XML (RSS), no CSV. El formato XML contiene las etiquetas <history> e <issuelinks> esenciales para reconstruir el flujo del proceso.
Límite de Filas: Las exportaciones estándar de Jira a menudo están limitadas a 1.000 problemas por exportación. Para conjuntos de datos más grandes, debe paginar la extracción ajustando el rango de fechas de JQL (ej., created >= '2023-01-01' AND created < '2023-02-01') y realizando múltiples exportaciones.
Filtro JQL: Asegúrese de que la clave project coincida con el identificador de su proyecto específico de Gestión de Problemas (ej., PROB, PM).
Zona Horaria del Sistema: Verifique que el perfil de usuario que realiza la exportación coincida con la zona horaria del sistema para asegurar la consistencia de las marcas de tiempo.
Permisos de Campo: El usuario debe tener permiso para ver el Historial de Cambios y los Problemas Vinculados para capturar transiciones y enlaces de Incidentes.
Campos Personalizados: Si 'Causa Raíz' o 'Solución Provisional' son campos personalizados, asegúrese de que la lógica de coincidencia de nombres de campo del script se alinee con los nombres de campo específicos en su instancia de Jira.

a Consulta de ejemplo config

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Pasos

Configuración de Requisitos Previos: Asegúrese de tener Python 3.x instalado junto con las librerías requests y pandas. Necesitará una cuenta de Jira Service Management con permisos de lectura para el proyecto relevante. Para Jira Cloud, genere un Token de API a través de la configuración de su cuenta de Atlassian. Para Data Center, genere un Token de Acceso Personal (PAT).
Identifique los IDs de Campos Personalizados: Jira Service Management utiliza IDs dinámicos para campos personalizados (ej., customfield_10012 para Grupo de Soporte o SLA). Antes de ejecutar la extracción principal, use un navegador o Postman para consultar un problema de Problema específico (/rest/api/2/issue/[ISSUE-KEY]) para identificar los IDs de campo específicos para 'Grupo de Soporte', 'Solución Provisional', 'Causa Raíz' y sus campos de SLA.
Configure el Script: Abra el script de Python proporcionado y actualice el diccionario CONFIG. Reemplace la URL, el correo electrónico del usuario y el Token de API. Actualice el diccionario FIELD_MAPPING con los nombres o IDs de campo personalizados reales que identificó en el Paso 2. Actualice la JQL_QUERY para apuntar a su proyecto específico (ej., project = PM AND issuetype = Problem).
Defina Mapeos de Estado: En el diccionario STATUS_MAPPING dentro del script, mapee los estados específicos de su flujo de trabajo de Jira (ej., 'En Investigación', 'Implementando', 'Resuelto') a los nombres de actividad estándar de ProcessMind (ej., 'Investigación Iniciada', 'Solución Permanente Aplicada').
Ejecute la Extracción: Ejecute el script a través de una terminal o IDE. El script utiliza la API de búsqueda de Jira con expand=changelog para extraer el estado actual y el historial completo de cada cambio de campo.
Lógica de Procesamiento: El script itera a través de cada problema. Primero crea un evento 'Registro de Problema Creado' a partir de la marca de tiempo de creación. Luego analiza el historial de cambios (changelog). Para cada elemento del historial, verifica si el campo cambiado coincide con nuestra lista de interés (Estado, Prioridad, Enlace, etc.) y genera una fila de evento correspondiente.
Manejo de SLA: El script intenta identificar incumplimientos de SLA buscando cambios en campos personalizados relacionados con SLA o transiciones de estado explícitamente nombradas 'Incumplido'. Ajuste la lógica en la función _parse_sla_breach si su sistema utiliza una automatización específica para marcar incumplimientos.
Transformación de Datos: El script aplana la estructura JSON anidada en un DataFrame tabular de Pandas. Las marcas de tiempo se convierten al formato ISO 8601.
Exportar: El conjunto de datos final se exporta a un archivo CSV llamado jira_problem_event_log.csv. Abra este archivo para verificar que los encabezados de las columnas coincidan con los requisitos de ProcessMind.
Cargar a ProcessMind: Importe el archivo CSV a ProcessMind. Mapee ProblemKey como ID de Caso, ActivityName como Actividad y EventTimestamp como Marca de Tiempo.

Configuración

Endpoint de API: Utiliza /rest/api/2/search (compatible con Cloud y la mayoría de las versiones de Data Center). La API v3 también es compatible, pero la v2 es generalmente más segura para una amplia compatibilidad.
Paginación: El script implementa la paginación usando startAt y maxResults para manejar grandes conjuntos de datos de manera eficiente. El tamaño de lote predeterminado se establece en 50.
Expansión de Changelog: El parámetro expand=changelog es crítico. Sin esto, solo se devuelve el estado actual y se pierde el historial/flujo del proceso.
Filtrado JQL: La consulta filtra por issuetype = Problem. Se recomienda encarecidamente añadir un filtro de rango de fechas (ej., created >= -180d) para limitar el volumen de datos durante las pruebas iniciales.
Autenticación: Soporta autenticación básica (Correo electrónico + Token) para Cloud. Para Data Center, modifique los encabezados para usar tokens Bearer.
Mapeo de Campos: Se requiere una configuración crítica. Los nombres de campo internos de Jira para 'Estado' y 'Prioridad' son estándar, pero 'Grupo de Soporte', 'Causa Raíz' y 'SLA' son casi siempre campos personalizados con IDs únicos (ej., customfield_12345).

a Consulta de ejemplo python

import requests
import pandas as pd
import json
from datetime import datetime
import base64

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        params = {
            class="hl-string">"jql": jql,
            class="hl-string">"startAt": start_at,
            class="hl-string">"maxResults": max_results,
            class="hl-string">"expand": class="hl-string">"changelog"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

Su Plantilla de Datos para la Gestión de Problemas

Su Plantilla de Datos para la Gestión de Problemas

Atributos de Gestión de Problemas

Actividades de Gestión de Problemas

Guías de Extracción

Exportación del Navegador de Problemas de Jira Service Management

Pasos

Configuración

a Consulta de ejemplo config

Extracción de Python vía Jira REST API con Changelog

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy mismo su Flujo de Gestión de Problemas

Su Plantilla de Datos para la Gestión de Problemas

Su Plantilla de Datos para la Gestión de Problemas

Atributos de Gestión de Problemas

Actividades de Gestión de Problemas

Guías de Extracción

Exportación del Navegador de Problemas de Jira Service Management

Pasos

Configuración

a Consulta de ejemplo config

Extracción de Python vía Jira REST API con Changelog

Pasos

Configuración

a Consulta de ejemplo python

Valoramos su privacidad

¿Listo para comenzar?

Optimice hoy mismo su Flujo de Gestión de Problemas