> Mejora continua de procesos > Gestión de problemas > Jira Service Management > Template de datos

Su Template de datos de Problem Management

Jira Service Management

Atributos de la gestión de problemas (20) Actividades de la gestión de problemas (14) Guías de extracción (2)

Su Template de datos de Problem Management

Este Template sirve como hoja de ruta integral para analizar sus Workflow de gestión de servicios de TI. Identifica los datos esenciales y los hitos del proceso en Jira Service Management. También ofrece una visión estructurada de los atributos y las actividades necesarios para comprender cómo gestiona su equipo los problemas subyacentes y el análisis de las causas raíz. Utilice estas pautas para agilizar la recopilación de datos y asegurarse de que sus iniciativas de Process Mining generen información útil para la acción.

Atributos recomendados para un análisis detallado
Hitos del proceso que debe capturar en su Registro de eventos
Orientación técnica para extraer datos

¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Descargar Template

Atributos de la gestión de problemas

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

5 Obligatorio 5 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	La acción específica o el cambio de estado que se produjo en el registro de problema.
Descripción Este atributo captura el nombre del evento o de la transición de estado que tiene lugar durante el ciclo de vida de la gestión de problemas. Algunos ejemplos son «Problem Logged», «Status Changed to Investigating» o «Root Cause Identified». Es esencial para asignar el flujo del proceso e identificar la secuencia de pasos seguida para resolver un problema. En Process Mining, estas actividades forman los nodos del mapa de procesos. Por qué es importante Define los pasos del mapa de procesos y permite analizar las variantes del proceso. Dónde obtenerlo Changelog de Jira (historial) o transiciones de estado de la incidencia Ejemplos Registro de problema creadoInvestigación iniciadaCausa raíz identificadaSolución alternativa actualizadaRegistro de problema cerrado
	Marca de tiempo EventTimestamp	La fecha y hora exactas en las que se produjo la actividad.
Descripción Este atributo registra el momento preciso en que tuvo lugar una actividad. Se utiliza para ordenar cronológicamente los eventos y calcular las duraciones entre pasos. Las marcas de tiempo precisas son fundamentales para calcular los tiempos de ciclo, como el tiempo desde «Problem Logged» hasta «Root Cause Identified», y para analizar el rendimiento a lo largo del tiempo. Por qué es importante Permite calcular todos los KPI basados en el tiempo y ordenar correctamente los eventos. Dónde obtenerlo Fecha de creación del Changelog de Jira o fecha de creación de la incidencia Ejemplos 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Registro de problema ProblemKey	El identificador único asignado al registro de problema en Jira Service Management.
Descripción Este atributo actúa como identificador central del caso para el análisis de Process Mining. Representa la clave única, por ejemplo, PM-1001, que Jira Service Management genera cuando se crea un nuevo registro de problema. Se utiliza para agrupar todas las actividades, los cambios de estado y las actualizaciones relacionadas en una única instancia de proceso de principio a fin. Analizar este atributo permite visualizar el ciclo de vida completo de un problema, desde su detección inicial hasta la investigación y el cierre definitivo. Por qué es importante Es la clave fundamental necesaria para reconstruir el flujo del proceso y hacer un seguimiento de registros de problemas específicos. Dónde obtenerlo Tabla de incidencias, campo «Key» o «Issue Key» Ejemplos PM-1023PM-4099PRB-3321PM-5001
	Sistema de origen SourceSystem	El nombre del sistema del que proceden los datos.
Descripción Identifica el sistema de software del que se extrajeron los datos del proceso. En este contexto, el valor es siempre «Jira Service Management». Este atributo resulta especialmente útil en entornos con varios sistemas para distinguir las fuentes de datos, aunque en esta vista concreta sirve principalmente como identificador estático de la trazabilidad de los datos. Por qué es importante Proporciona contexto sobre el origen de los datos, especialmente al combinar información con otros datos de IT Service Management. Dónde obtenerlo Configuración codificada o del sistema Ejemplos Jira Service ManagementJira CloudJSM-Prod
	Última actualización de datos LastDataUpdate	La marca de tiempo en la que se extrajeron los datos o se actualizaron por última vez.
Descripción Indica cuándo se sincronizó por última vez el conjunto de datos con el entorno activo de Jira Service Management. Esto permite a las personas analistas conocer la actualidad de los datos. Se utiliza para validar que el análisis refleja el estado más reciente del proceso e identificar posibles problemas de latencia de datos. Por qué es importante Garantiza la actualidad de los datos y ayuda a confiar en los resultados del análisis. Dónde obtenerlo Marca de tiempo de ETL Ejemplos 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Categoría de la causa raíz RootCauseCategory	La clasificación de la causa subyacente del problema.
Descripción Clasifica el fallo técnico o del proceso que causó el problema, como «Software Bug», «Human Error» o «Hardware Failure». En Jira Service Management, suele ser un campo personalizado. Este atributo respalda el Dashboard «Root Cause Category Distribution» y permite tomar decisiones estratégicas sobre dónde invertir en infraestructura o capacitación para evitar que el problema se repita. Por qué es importante Clave para identificar problemas sistémicos y orientar las medidas preventivas. Dónde obtenerlo Campo personalizado «Root Cause» o «Root Cause Category» Ejemplos Error de softwareError de configuraciónProblema de capacidadProblema con el proveedor
	Grupo de soporte asignado SupportGroup	El equipo técnico o grupo asignado actualmente para investigar el problema.
Descripción Identifica el equipo específico responsable del registro del problema en el momento del evento. En Jira Service Management, suele asignarse a «Component» o a un campo personalizado como «Support Group». Este atributo es fundamental para el Dashboard «Support Group Handover Bottlenecks», ya que permite a los analistas visualizar cómo se desplazan los problemas entre equipos y dónde permanecen durante más tiempo. Por qué es importante Esencial para el análisis organizativo y la identificación de fricciones entre equipos. Dónde obtenerlo Campo de incidencia «Component» o campo personalizado «Support Group» Ejemplos Administración de bases de datosOperaciones de redSoporte de aplicaciones, nivel 2
	Prioridad Priority	El nivel de criticidad asignado al registro del problema.
Descripción Indica la urgencia y el impacto del problema, normalmente desde «Low» hasta «Critical». Este campo se utiliza para segmentar el análisis y garantizar que los problemas de alta prioridad se resuelvan dentro de los objetivos del SLA. El análisis de este atributo ayuda en el Dashboard «SLA Compliance and Target Trends» a comprobar si los riesgos empresariales críticos reciben la prioridad adecuada. Por qué es importante Permite segmentar el rendimiento del proceso según la criticidad empresarial. Dónde obtenerlo Campo de incidencia «Priority» Ejemplos MáximaAltaMediaBaja
	Resumen del problema ProblemSummary	La descripción breve o el título del registro del problema.
Descripción Contiene el resumen principal del registro del problema. Aunque se basa principalmente en texto, proporciona contexto a los analistas que revisan casos individuales en la herramienta de Process Mining. Permite buscar palabras clave y realizar análisis cualitativos sobre los tipos de problemas registrados. Por qué es importante Proporciona un contexto comprensible para el identificador del caso. Dónde obtenerlo Campo de incidencia «Summary» Ejemplos Tiempo de espera agotado para la conexión a la base de datos en la región de la UEAumento repentino de la latencia del servicio de correo electrónicoCola de procesamiento de pedidos bloqueada
	Usuario UserKey	El identificador único o el nombre de la persona usuaria que realizó la actividad.
Descripción Captura la identidad de la persona o cuenta del sistema responsable de ejecutar la actividad específica. Puede tratarse de la persona «Assignee» que actualiza el registro o de la persona «Author» de un cambio de estado. Estos datos se utilizan para analizar el uso de los recursos, identificar cuellos de botella en las transferencias entre personas usuarias y garantizar la responsabilidad dentro del proceso de gestión de problemas. Por qué es importante Esencial para analizar los traspasos, la segregación de funciones y la carga de trabajo de los recursos. Dónde obtenerlo Campo «author» de Jira en el changelog o campo «assignee» en la incidencia Ejemplos j.smithsystem_automationm.doe
	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 del problema, como «Fixed», «Won't Fix», «Duplicate» o «Cannot Reproduce». Se utiliza para filtrar los problemas resueltos correctamente de aquellos cerrados por motivos administrativos y garantizar que los cálculos de KPI, como «Mean Time to Root Cause», sean precisos. Por qué es importante Distingue entre soluciones eficaces y cierres administrativos. Dónde obtenerlo Campo de incidencia «Resolution» Ejemplos HechoNo se realizaráDuplicadoNo se puede reproducir
	Estado de incumplimiento del SLA SlaBreachStatus	Indica si el registro del problema ha incumplido su acuerdo de nivel de servicio.
Descripción Campo booleano o de estado que indica si el tiempo de resolución ha superado el objetivo acordado. Ayuda en el Dashboard «SLA Compliance and Target Trends». Destaca los casos que exponen a la organización a riesgos de incumplimiento o sanciones. Por qué es importante Fundamental para el cumplimiento y la monitorización del rendimiento. Dónde obtenerlo Lógica del campo SLA de Jira Service Management Ejemplos CumplidoIncumplidoEn pausa
	Fecha de creación CreatedDate	La fecha en que se creó el registro del problema.
Descripción La marca de tiempo en que el problema se registró por primera vez en el sistema. Aunque la marca de tiempo del evento gestiona la cronología de la actividad, este atributo específico suele utilizarse para filtros de alto nivel, por ejemplo, «Mostrarme todos los problemas creados en el primer trimestre». Sirve como punto de referencia para el análisis de antigüedad. Por qué es importante Fecha de referencia para analizar la antigüedad y el volumen de entradas. Dónde obtenerlo Campo de incidencia «Created» Ejemplos 2023-01-012023-06-15
	Número de incidencias vinculadas LinkedIncidentCount	El número de incidencias vinculadas a este registro del problema.
Descripción Recuento de tickets de incidencia asociados al registro del problema. Este atributo cuantifica el impacto del problema en la base de usuarios. Se utiliza en el KPI «Incident to Problem Linkage Depth» para priorizar los problemas que generan el mayor volumen de tickets de soporte. Por qué es importante Cuantifica el impacto empresarial según el volumen de incidencias. Dónde obtenerlo Recuento de vínculos en la tabla «issuelinks» cuyo tipo es «Problem/Incident» Ejemplos 011550
	Origen de la detección DetectionSource	Cómo se identificó el problema, por ejemplo, de forma proactiva o reactiva.
Descripción Indica el origen de la identificación del problema. Entre los valores habituales se incluyen «Proactive Monitoring», «Service Desk Incident» o «Vendor Notification». Este atributo se utiliza en el Dashboard «Proactive vs Reactive Identification» para medir la madurez del proceso de gestión de problemas. Por qué es importante Mide la madurez del proceso y la eficacia de los sistemas de monitorización. Dónde obtenerlo Campo personalizado «Source» o «Detection Source» Ejemplos Supervisión proactivaEscalamiento del incidenteNotificación al proveedor
	PIR realizado ReviewStatus	Indica si se realizó una revisión posterior a la implementación (PIR).
Descripción Registra si la actividad o el indicador «Post Implementation Review» está presente en el caso. Es esencial para el Dashboard «Post Implementation Review Compliance». Garantiza que la organización cumpla los requisitos de gobernanza para la mejora continua. Por qué es importante Métrica de cumplimiento para el aprendizaje organizativo. Dónde obtenerlo Campo personalizado «PIR Status» o existencia de la actividad «PIR» Ejemplos CompletadoPendienteNo requerido
	Reportador ReporterName	El usuario que registró originalmente el problema.
Descripción Identifica a la persona que creó el registro del problema. Es diferente del asignatario. El análisis de los reportadores ayuda a comprender dónde se detectan los problemas, por ejemplo, en agentes del Service Desk o administradores de sistemas. Añade contexto al análisis «Proactive vs Reactive». Por qué es importante Identifica el origen de la entrada de problemas. Dónde obtenerlo Campo de incidencia «Reporter» Ejemplos monitoring_servicehelpdesk_leadnetwork_admin
	Se ha reabierto IsReopened	Indicador que señala si el problema se reabrió después del cierre.
Descripción Indicador booleano que se establece en true si el registro del problema pasó de un estado cerrado a un estado abierto. Esto respalda el análisis «Problem Reopened Rate Analysis». Una tasa elevada de reaperturas indica problemas de calidad en las soluciones permanentes o procedimientos de verificación insuficientes. Por qué es importante Indicador de calidad de la eficacia de las soluciones. Dónde obtenerlo Derivado de las transiciones de estado Ejemplos truefalse
	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 vínculo es fundamental para el Dashboard «Change Request Initiation Lag». Conecta el proceso de gestión de problemas con la gestión de cambios y permite realizar análisis entre procesos. Por qué es importante Conecta la investigación con la corrección en el proceso de gestión de cambios. Dónde obtenerlo Vínculos de incidencia cuyo tipo es «is fixed by» o similar Ejemplos CR-404CHG-1099CR-5512
	Solución alternativa disponible WorkaroundDetails	Indica si se ha documentado una solución alternativa para el problema.
Descripción Registra si existe o se ha publicado el texto de una solución alternativa temporal. Esto permite a la organización realizar un seguimiento de la «Workaround Publication Speed». El análisis de este campo ayuda a determinar con qué rapidez el equipo puede restablecer la estabilidad del servicio, incluso antes de encontrar una solución permanente. Por qué es importante Clave para medir la rapidez del alivio provisional proporcionado al negocio. Dónde obtenerlo Campo personalizado «Workaround» Ejemplos Reiniciar el servicioBorrar la caché del navegadorNo se proporcionó ninguno

Obligatorio Recomendado Opcional

Actividades de la gestión de problemas

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir con precisión sus Workflows de resolución.

8 Recomendado 6 Opcional

	Actividad	Descripción
	Asignado a un grupo de soporte	La asignación del registro de problema a un equipo técnico o grupo de soporte específico. Se realiza un seguimiento mediante los cambios en el campo personalizado «Support Group» o en el campo «Assignee» si no se utilizan grupos.
Por qué es importante Es fundamental para analizar las transferencias y los cuellos de botella entre equipos. Unas tasas elevadas de transferencia pueden indicar ineficiencias en el enrutamiento. Dónde obtenerlo Historial de incidencias de Jira: cambio del campo «Support Group» o «Assignee» Recopilar Se registra cuando cambia el campo de asignación Tipo de evento explicit
	Causa raíz identificada	El momento en que se registra formalmente la causa subyacente. Se infiere a partir de un cambio de estado a «Root Cause Identified» o de la cumplimentación del campo «Root Cause».
Por qué es importante Un hito importante que pone fin a la fase de investigación. Es esencial para calcular el «Mean Time to Root Cause Discovery». Dónde obtenerlo Historial de incidencias de Jira: estado cambiado a «Root Cause Identified» O campo «Root Cause» cumplimentado Recopilar Compare el campo de estado o compruebe si el campo está cumplimentado Tipo de evento inferred
	Incidente vinculado al problema	La acción de vincular una incidencia de incidente relacionada con el registro de problema. Se captura en la tabla de vínculos de incidencias o en el historial.
Por qué es importante Determina el impacto y el alcance del problema. Es esencial para el KPI «Incident to Problem Linkage Depth» y para priorizar según el impacto empresarial. Dónde obtenerlo Vínculos de incidencias de Jira: vínculo creado con el tipo «causes» o «relates to» Recopilar Se registra cuando se crea un vínculo entre incidencias Tipo de evento explicit
	Investigación iniciada	La transición del estado del problema a un estado de investigación activa, por ejemplo, «Under Investigation» o «In Progress». Marca el inicio de la fase de trabajo activo.
Por qué es importante Inicia el contador del tiempo de ciclo de la investigación. Ayuda a distinguir el tiempo de espera en el backlog del tiempo real de análisis activo. Dónde obtenerlo Historial de incidencias de Jira: estado cambiado a «Under Investigation» o «In Progress» Recopilar Compare las actualizaciones del campo de estado Tipo de evento inferred
	Registro de problema cerrado	La finalización definitiva del ciclo de vida del problema. Se captura explícitamente cuando el estado cambia a «Closed».
Por qué es importante El final definitivo de la instancia del proceso. Es necesario para calcular el tiempo de ciclo total y las tasas de cierre. Dónde obtenerlo Historial de incidencias de Jira: estado cambiado a «Closed» Recopilar Se registra cuando el estado cambia a Closed Tipo de evento explicit
	Registro de problema creado	El evento inicial en el que se crea la incidencia de problema en el sistema. Se captura explícitamente en el historial de la incidencia mediante 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 analizar el volumen. Es esencial para calcular el rendimiento y las tasas de entrada. Dónde obtenerlo Tabla de incidencias de Jira: marca de tiempo de la fecha de creación o pestaña Historial: evento de incidencia creada Recopilar Se registra cuando se confirma la transacción de creación de la incidencia Tipo de evento explicit
	Resolución verificada	La confirmación de que la solución ha resuelto eficazmente el problema. Se infiere a partir de una transición de estado a «Resolved» o a un estado específico «Verified».
Por qué es importante Punto de control de calidad que garantiza el funcionamiento de la solución. Los retrasos aquí indican cuellos de botella en las pruebas o en la aceptación por parte de las personas usuarias. Dónde obtenerlo Historial de incidencias de Jira: estado cambiado a «Resolved» o «Verified» Recopilar Compare las actualizaciones del campo de estado Tipo de evento inferred
	Solución alternativa actualizada	La creación o actualización del campo de texto «Workaround». Este evento indica que se ha documentado una solución temporal.
Por qué es importante Mide la rapidez con la que se proporciona alivio al negocio. Es fundamental para el KPI «Workaround Availability Lead Time». Dónde obtenerlo Historial de incidencias de Jira: campo «Workaround» modificado (no nulo) Recopilar Se registra cuando se modifica el campo Workaround Tipo de evento explicit
	Prioridad del problema modificada	Una actualización del campo Priority del registro de problema. Se captura supervisando los cambios del campo «Priority» en la pestaña Historial.
Por qué es importante Indica una escalación o desescalación del problema. Su análisis ayuda a identificar la precisión de la clasificación inicial y la antigüedad del backlog de alta prioridad. Dónde obtenerlo Historial de incidencias de Jira: el campo «Priority» cambió de Old Value a New Value Recopilar Se registra cuando se actualiza el campo Priority Tipo de evento explicit
	Problema reabierto	La transición de un problema desde el estado «Resolved» o «Closed» a un estado activo. Indica una corrección fallida o una resolución rechazada.
Por qué es importante Una métrica de calidad principal. Unas tasas elevadas de reapertura indican un análisis de causa raíz o unas pruebas poco eficaces. Dónde obtenerlo Historial de incidencias de Jira: estado cambiado de «Closed»/«Resolved» a «Open»/«In Progress» Recopilar Compare la secuencia del campo de estado Tipo de evento inferred
	Revisión posterior a la implementación	La ejecución de una revisión después de aplicar la solución. Se captura mediante un cambio de estado a «In Review» o mediante actualizaciones de campos específicos de PIR.
Por qué es importante Actividad de cumplimiento que garantiza que se documenten las lecciones aprendidas. Es compatible con el análisis de «Post Implementation Review Compliance». Dónde obtenerlo Historial de incidencias de Jira: estado cambiado a «In Review» O campo «PIR Notes» actualizado Recopilar Compare el campo de estado o las actualizaciones de los campos PIR Tipo de evento inferred
	SLA incumplido	Un evento que indica que el tiempo de resolución del problema superó el Acuerdo de Nivel de Servicio definido. Se calcula comparando la fecha objetivo del SLA con la fecha de resolución.
Por qué es importante Es fundamental para los informes de cumplimiento. Ayuda a identificar qué prioridades o categorías incumplen los objetivos con mayor frecuencia. Dónde obtenerlo Registros de SLA de Jira Service Management: «Time to Resolution» > Target, o valor calculado Recopilar Se obtiene de los datos del campo SLA o comparando Due Date con Resolution Date Tipo de evento calculated
	Solicitud de cambio vinculada	La vinculación de una Request for Change (RFC) con el registro de problema. 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 corrección. Es compatible con el KPI «Change Management Transition Delay». Dónde obtenerlo Vínculos de incidencias de Jira: vínculo creado con el tipo «is fixed by» o vinculación con un tipo de incidencia «Change» Recopilar Se registra cuando se crea un vínculo con un tipo de incidencia Change Tipo de evento explicit
	Solución permanente aplicada	La transición que indica que se ha implementado la solución. Normalmente se infiere a partir de un cambio de estado a «Implementing» o «Fixed».
Por qué es importante Marca el final del trabajo de corrección técnica. Se utiliza para medir el tiempo de ciclo de implementación. Dónde obtenerlo Historial de incidencias de Jira: estado cambiado a «Implemented», «Pending Verification» o «Fixed» Recopilar Compare las actualizaciones del 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 desde un navegador web con una cuenta que tenga permisos de «Browse Projects» para el proyecto de Problem Management.
Vaya a la barra de menú superior y seleccione Filters; después, haga clic en Advanced Issue Search para abrir el Issue Navigator.
Cambie el modo de búsqueda a JQL (Jira Query Language) en lugar de Basic, si aún no está seleccionado.
Introduzca la cadena de consulta JQL específica proporcionada en la sección Query para aislar los registros de Problem, por ejemplo, project = 'Problem Management'. Asegúrese de que el intervalo de tiempo sea adecuado para los límites de exportación del sistema.
Haga clic en el botón Search para comprobar que la lista de incidencias devuelve los registros de Problem esperados.
Localice el botón Export en la esquina superior derecha de la interfaz del Issue Navigator.
Seleccione Export XML en el menú desplegable. No seleccione CSV, ya que la exportación CSV estándar solo proporciona datos del estado actual y no incluye los registros históricos de cambios necesarios para el Process Mining.
Guarde el archivo XML generado, por ejemplo, jira_export.xml, en un directorio local accesible para su entorno de procesamiento.
Prepare el entorno de Python instalando la biblioteca pandas si aún no está instalada.
Ejecute el script de Python proporcionado en la sección Query y asegúrese de que la variable de ruta del archivo coincida con la ubicación donde guardó el archivo.
El script analiza la estructura RSS/XML y extrae la marca de tiempo «Created», las entradas de «History» correspondientes a cambios de estado, prioridad y asignación, y los «Issue Links» de las incidencias relacionadas.
El script calcula los incumplimientos del SLA comparando las fechas de resolución con las fechas límite y genera un Registro de eventos en formato CSV listo para ProcessMind.

Configuración

Formato de exportación: Debe utilizar la exportación XML (RSS), no CSV. El formato XML contiene las etiquetas <history> y <issuelinks>, esenciales para reconstruir el flujo del proceso.
Límite de filas: Las exportaciones estándar de Jira suelen estar limitadas a 1.000 incidencias por exportación. Para conjuntos de datos más grandes, debe paginar la extracción ajustando el intervalo de fechas de JQL, por ejemplo, created >= '2023-01-01' AND created < '2023-02-01', y realizando varias exportaciones.
Filtro JQL: Asegúrese de que la clave project coincida con el identificador específico de su proyecto de Problem Management, por ejemplo, PROB, PM.
Zona horaria del sistema: Compruebe que el perfil de usuario que realiza la exportación utilice la misma zona horaria que el sistema para garantizar la coherencia de las marcas de tiempo.
Permisos de campos: El usuario debe tener permiso para ver el historial de cambios y las incidencias vinculadas, a fin de capturar las transiciones y los vínculos con Incident.
Campos personalizados: Si «Root Cause» o «Workaround» son campos personalizados, asegúrese de que la lógica de correspondencia de nombres de campo del script coincida con los nombres específicos de su instancia de Jira.

a Consulta de ejemplo sql

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 instalado Python 3.x junto con las bibliotecas requests y pandas. Necesitará una cuenta de Jira Service Management con permisos de lectura para el proyecto correspondiente. En Jira Cloud, genere un token de API desde la configuración de su cuenta de Atlassian. En Data Center, genere un Personal Access Token (PAT).
Identificación de los identificadores de campos personalizados: Jira Service Management utiliza identificadores dinámicos para los campos personalizados, por ejemplo, customfield_10012 para Support Group o SLA. Antes de ejecutar la extracción principal, utilice un navegador o Postman para consultar una incidencia de Problem específica (/rest/api/2/issue/[ISSUE-KEY]) e identificar los identificadores de campo de «Support Group», «Workaround», «Root Cause» y sus campos de SLA.
Configuración del script: Abra el script de Python proporcionado y actualice el diccionario CONFIG. Sustituya la URL, el correo electrónico del usuario y el token de API. Actualice el diccionario FIELD_MAPPING con los nombres o identificadores reales de los campos personalizados identificados en el paso 2. Actualice JQL_QUERY para dirigirse a su proyecto específico, por ejemplo, project = PM AND issuetype = Problem.
Definición de las correspondencias de estados: En el diccionario STATUS_MAPPING del script, asigne los estados específicos de su Workflow de Jira, por ejemplo, «Under Investigation», «Implementing» y «Resolved», a los nombres de actividad estándar de ProcessMind, por ejemplo, «Investigation Started» y «Permanent Fix Applied».
Ejecución de la extracción: Ejecute el script desde un terminal o IDE. El script utiliza la API de búsqueda de Jira con expand=changelog para obtener el estado actual y el historial completo de cambios de cada campo.
Lógica de procesamiento: El script recorre cada incidencia. Primero crea un evento «Problem Record Created» a partir de la marca de tiempo de creación. Después analiza el historial de cambios. Para cada elemento del historial, comprueba si el campo modificado coincide con nuestra lista de interés, como Status, Priority o Link, y genera la fila de evento correspondiente.
Gestión del SLA: El script intenta identificar los incumplimientos del SLA buscando cambios en campos personalizados relacionados con el SLA o transiciones de estado denominadas explícitamente «Breached». Ajuste la lógica de la función _parse_sla_breach si su sistema utiliza una automatización específica para marcar los incumplimientos.
Transformación de datos: El script aplana la estructura JSON anidada y la convierte en un DataFrame tabular de Pandas. Las marcas de tiempo se convierten al formato ISO 8601.
Exportación: El conjunto de datos final se exporta a un archivo CSV llamado jira_problem_event_log.csv. Abra este archivo para comprobar que los encabezados de columna coincidan con los requisitos de ProcessMind.
Carga en ProcessMind: Importe el archivo CSV en ProcessMind. Asigne ProblemKey como Case ID, ActivityName como Activity y EventTimestamp como Timestamp.

Configuración

Endpoint de la API: Utiliza /rest/api/2/search, compatible con Cloud y con la mayoría de las versiones de Data Center. También se admite la API v3, pero la v2 suele ofrecer una compatibilidad más amplia.
Paginación: El script implementa la paginación mediante startAt y maxResults para gestionar grandes conjuntos de datos de forma eficiente. El tamaño de lote predeterminado es 50.
Expansión de Changelog: El parámetro expand=changelog es fundamental. Sin él, solo se devuelve el estado actual y se pierde el historial y el flujo del proceso.
Filtrado JQL: La consulta filtra por issuetype = Problem. Se recomienda añadir un filtro de intervalo de fechas, por ejemplo, created >= -180d, para limitar el volumen de datos durante las pruebas iniciales.
Autenticación: Admite Basic Auth, con correo electrónico y token, para Cloud. En Data Center, modifique los encabezados para utilizar tokens Bearer.
Asignación de campos: Se requiere una configuración crítica. Los nombres internos de Jira para «Status» y «Priority» son estándar, pero «Support Group», «Root Cause» y «SLA» casi siempre son campos personalizados con identificadores únicos, por ejemplo, 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}")

¿Listo para comenzar?

Convierta hoy sus datos de Problem Management en información útil para la acción. Descargue la guía o póngase en contacto con nuestro equipo de soporte para iniciar su recorrido de Process Mining.

Volver a la guía de mejora Descargar Template

Optimice hoy su flujo de Problem Management

Reduzca los tiempos de ciclo un 30 % y estabilice su entorno de TI.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Configuración en minutos.

Su Template de datos de Problem Management

Su Template de datos de Problem Management

Atributos de la gestión de problemas

Actividades de la gestión de problemas

Guías de extracción

Exportación del Issue Navigator de Jira Service Management

Pasos

Configuración

a Consulta de ejemplo sql

Extracción con Python mediante la API REST de Jira y Changelog

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy su flujo de Problem Management

Su Template de datos de Problem Management

Su Template de datos de Problem Management

Atributos de la gestión de problemas

Actividades de la gestión de problemas

Guías de extracción

Exportación del Issue Navigator de Jira Service Management

Pasos

Configuración

a Consulta de ejemplo sql

Extracción con Python mediante la API REST de Jira y Changelog

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy su flujo de Problem Management

Valoramos su privacidad