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

Su Template de datos para la gestión de problemas

Jira Service Management

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

Su Template de datos para la gestión de problemas

Este Template ofrece una guía completa para analizar los flujos de trabajo de gestión de servicios de TI. Identifica los datos esenciales y los hitos del proceso en Jira Service Management. También presenta de forma estructurada los atributos y las actividades necesarios para entender cómo gestiona su equipo los problemas subyacentes y analiza sus causas raíz. Siga estas pautas para agilizar la recopilación de datos y obtener información útil para la acción con sus iniciativas de Process Mining.

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

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

Descargar Template

Atributos de gestión de problemas

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar de forma completa el ciclo de vida de la gestión de problemas.

5 Obligatorio 5 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	Acción específica o cambio de estado que se produjo en el registro de problema.
Descripción Este atributo recoge el nombre del evento o de la transición de estado que se produce durante el ciclo de vida de la gestión de problemas. Algunos ejemplos son «Problema registrado», «Estado cambiado a En investigación» o «Causa raíz identificada». Es esencial para mapear el flujo del proceso e identificar la secuencia de pasos necesarios para resolver un problema. En Process Mining, estas actividades forman los nodos del mapa del proceso. Por qué es importante Define los pasos del mapa del proceso y permite analizar las variantes del proceso. Dónde obtenerlo Registro de cambios de Jira (historial) o transiciones de estado de la incidencia Ejemplos Registro de problema creadoInvestigación iniciadaCausa raíz identificadaSolución temporal actualizadaRegistro de problema cerrado
	Marca de tiempo EventTimestamp	Fecha y hora exactas en que se produjo la actividad.
Descripción Este atributo registra el momento exacto en que tuvo lugar una actividad. Se utiliza para ordenar cronológicamente los eventos y calcular la duración entre pasos. Las marcas de tiempo precisas son fundamentales para calcular los tiempos de ciclo, como el tiempo transcurrido entre «Problema registrado» y «Causa raíz identificada», 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 registro de cambios 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	Identificador único asignado al registro de problema en Jira Service Management.
Descripción Este atributo funciona como identificador central del caso para el análisis de Process Mining. Representa la clave única, por ejemplo, PM-1001, que genera Jira Service Management al crear un registro de problema. Se utiliza para agrupar todas las actividades, los cambios de estado y las actualizaciones relacionadas en una sola instancia del 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 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	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 caso, el valor siempre es «Jira Service Management». Este atributo resulta especialmente útil en entornos con varios sistemas para distinguir las fuentes de datos. En esta vista específica, sin embargo, sirve principalmente como identificador estático del linaje de los datos. Por qué es importante Aporta contexto sobre el origen de los datos, especialmente al combinarlos con otros datos de gestión de servicios de TI. Dónde obtenerlo Valor codificado o configuración del sistema Ejemplos Jira Service ManagementJira CloudJSM-Prod
	Última actualización de datos LastDataUpdate	Fecha y hora en que se extrajeron o actualizaron los datos 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. Así, los analistas pueden saber si los datos están actualizados. Permite comprobar que el análisis refleja el estado más reciente del proceso e identificar posibles retrasos en la disponibilidad de los datos. Por qué es importante Permite comprobar que los datos están actualizados y ayuda a confiar en los resultados del análisis. Dónde obtenerlo Fecha y hora de ETL Ejemplos 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Categoría de causa raíz RootCauseCategory	Clasificación de la causa subyacente del problema.
Descripción Clasifica el fallo técnico o del proceso que causó el problema, por ejemplo, «Error de software», «Error humano» o «Fallo de hardware». Suele ser un campo personalizado de Jira Service Management. Este atributo permite crear el Dashboard «Distribución por categoría de causa raíz» y tomar decisiones estratégicas sobre dónde invertir en infraestructura o formació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	Equipo técnico o grupo asignado actualmente a investigar el problema.
Descripción Identifica al equipo responsable del registro del problema en el momento del evento. En Jira Service Management, suele corresponder al campo «Component» o a un campo personalizado como «Support Group». Este atributo es fundamental para el Dashboard «Cuellos de botella en los traspasos entre grupos de soporte», que permite visualizar cómo pasan los problemas de un equipo a otro y dónde permanecen más tiempo. Por qué es importante Esencial para analizar la organización e identificar 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 de nivel 2
	Prioridad Priority	Nivel de criticidad asignado al registro del problema.
Descripción Indica la urgencia y el impacto del problema, normalmente desde «Baja» hasta «Crítico». Este campo permite segmentar el análisis y comprobar que los problemas de alta prioridad se resuelvan dentro de los objetivos del SLA. El análisis de este atributo ayuda a verificar, en el Dashboard «Cumplimiento del SLA y tendencias de los objetivos», si los riesgos críticos para el negocio reciben la prioridad adecuada. Por qué es importante Permite segmentar el rendimiento del proceso según la criticidad para el negocio. Dónde obtenerlo Campo de incidencia «Priority» Ejemplos MáximaAltaMediaBaja
	Resumen del problema ProblemSummary	Descripción breve o título del registro del problema.
Descripción Contiene el resumen principal del registro del problema. Aunque es principalmente texto, aporta contexto a los analistas que revisan casos individuales en la herramienta de Process Mining. Permite buscar palabras clave y analizar cualitativamente los tipos de problemas registrados. Por qué es importante Aporta contexto legible para las personas junto al identificador del caso. Dónde obtenerlo Campo de incidencia «Summary» Ejemplos Tiempo de espera agotado en la conexión a la base de datos de la región de la UEAumento repentino de la latencia del servicio de correo electrónicoCola de procesamiento de pedidos bloqueada
	Usuario UserKey	Identificador único o nombre del usuario que realizó la actividad.
Descripción Registra la identidad de la persona o cuenta del sistema responsable de realizar la actividad concreta. Puede ser el «Responsable» que actualizó el registro o el «Autor» de un cambio de estado. Estos datos se utilizan para analizar el uso de los recursos, detectar cuellos de botella en los traspasos entre usuarios y garantizar la rendición de cuentas en el 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 registro de cambios o campo «assignee» de la incidencia Ejemplos j.smithsystem_automationm.doe
	Código de resolución ResolutionCode	Código que indica cómo se resolvió el problema.
Descripción Especifica el resultado final del registro del problema, por ejemplo, «Corregido», «No se corregirá», «Duplicado» o «No se puede reproducir». Se utiliza para distinguir los problemas resueltos correctamente de los cerrados por motivos administrativos y garantizar que los cálculos de KPI, como «Tiempo medio hasta identificar la causa raíz», sean precisos. Por qué es importante Distingue entre las correcciones efectivas y los 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 el acuerdo de nivel de servicio.
Descripción Campo booleano o de estado que indica si el tiempo de resolución superó el objetivo acordado. Ayuda a crear el Dashboard «Cumplimiento del SLA y tendencias de los objetivos». Destaca los casos que exponen a la organización a riesgos de incumplimiento o sanciones. Por qué es importante Esencial para supervisar el cumplimiento y el rendimiento. Dónde obtenerlo Lógica del campo SLA de Jira Service Management Ejemplos CumplidoIncumplidoEn pausa
	Fecha de creación CreatedDate	Fecha en que se creó el registro del problema.
Descripción Fecha y hora en que se registró el problema por primera vez en el sistema. La fecha y hora del evento indican cuándo tuvo lugar la actividad; este atributo específico suele utilizarse para aplicar filtros generales, por ejemplo, «Mostrar todos los problemas creados en el primer trimestre». Sirve como referencia para el análisis de antigüedad. Por qué es importante Fecha de referencia para analizar la antigüedad y el volumen de problemas recibidos. Dónde obtenerlo Campo de incidencia «Created» Ejemplos 2023-01-012023-06-15
	Informante ReporterName	Usuario que registró originalmente el problema.
Descripción Identifica a la persona que creó el registro del problema. No es lo mismo que el responsable asignado. Analizar quién informa los problemas ayuda a entender dónde se detectan, por ejemplo, entre el personal de la mesa de ayuda o los administradores de sistemas. Aporta contexto al análisis «Proactivo frente a reactivo». Por qué es importante Identifica el origen de la notificación del problema. Dónde obtenerlo Campo de incidencia «Reporter» Ejemplos servicio_supervisionresponsable_mesa_ayudaadministrador_red
	Número de incidencias vinculadas LinkedIncidentCount	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 «Profundidad de la vinculación entre incidencias y problemas» para priorizar los problemas que generan más tickets de soporte. Por qué es importante Cuantifica el impacto en el negocio 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 cómo se detectó el problema. Algunos valores habituales son «Supervisión proactiva», «Incidencia de la mesa de ayuda» o «Notificación del proveedor». Este atributo se utiliza en el Dashboard «Identificación proactiva frente a reactiva» 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 supervisión. Dónde obtenerlo Campo personalizado «Source» o «Detection Source» Ejemplos Supervisión proactivaEscalamiento de una incidenciaNotificación del proveedor
	Revisión posterior a la implementación realizada ReviewStatus	Indica si se realizó una revisión posterior a la implementación (PIR).
Descripción Registra si el caso incluye la actividad o el indicador «Revisión posterior a la implementación». Es esencial para el Dashboard «Cumplimiento de la revisión posterior a la implementación». Permite comprobar que la organización cumple los requisitos de gobernanza para la mejora continua. Por qué es importante Métrica de cumplimiento para el aprendizaje organizacional. Dónde obtenerlo Campo personalizado «PIR Status» o existencia de la actividad «PIR» Ejemplos CompletadoPendienteNo es necesario
	Se volvió a abrir IsReopened	Indicador que señala si el problema se volvió a abrir después de cerrarse.
Descripción Indicador booleano que se establece en verdadero si el registro del problema pasó de cerrado a abierto. Permite analizar la «Tasa de reapertura de problemas». Una tasa elevada de reapertura puede indicar problemas de calidad en las soluciones definitivas o procedimientos de verificación insuficientes. Por qué es importante Indicador de calidad de la eficacia de las soluciones. Dónde obtenerlo Se obtiene a partir de las transiciones de estado Ejemplos truefalse
	Solicitud de cambio vinculada LinkedChangeRequest	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 definitiva. Este vínculo es fundamental para el Dashboard «Retraso en el inicio de solicitudes de cambio». Conecta el proceso de gestión de problemas con el de gestión de cambios y permite analizar ambos procesos en conjunto. 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 incidencias cuyo tipo es «is fixed by» o similar Ejemplos CR-404CHG-1099CR-5512
	Solución temporal disponible WorkaroundDetails	Indica si se ha documentado una solución temporal para el problema.
Descripción Registra si existe o se ha publicado una descripción de una solución temporal. Esto permite medir la «Velocidad de publicación de soluciones temporales». El análisis de este campo ayuda a determinar con qué rapidez puede el equipo restablecer la estabilidad del servicio antes de encontrar una solución definitiva. Por qué es importante Clave para medir la rapidez con que se ofrece un alivio temporal al negocio. Dónde obtenerlo Campo personalizado «Workaround» Ejemplos Reiniciar el servicioBorrar la caché del navegadorNo se proporcionó ninguna

Obligatorio Recomendado Opcional

Actividades de gestión de problemas

Estos son los pasos e hitos clave que debe incluir en el Registro de eventos para descubrir con precisión los flujos de trabajo de resolución.

8 Recomendado 6 Opcional

	Actividad	Descripción
	Asignado a un grupo de soporte	Asignación del registro de problema a un equipo técnico o grupo de soporte específico. Se hace un seguimiento de este cambio mediante las modificaciones del campo personalizado «Grupo de soporte» o del campo «Persona asignada» si no se utilizan grupos.
Por qué es importante Es fundamental para analizar los traspasos y los cuellos de botella entre equipos. Una tasa elevada de traspasos puede indicar ineficiencias en el enrutamiento. Dónde obtenerlo Historial de incidencias de Jira: se modificó el campo «Grupo de soporte» o «Persona asignada» Capturar Se registra cuando cambia el campo de asignación Tipo de evento explicit
	Causa raíz identificada	Momento en que se registra formalmente la causa subyacente. Se deduce de un cambio de estado a «Causa raíz identificada» o de la cumplimentación del campo «Causa raíz».
Por qué es importante Hito importante que pone fin a la fase de investigación. Es esencial para calcular el «Tiempo medio hasta descubrir la causa raíz». Dónde obtenerlo Historial de incidencias de Jira: el estado cambió a «Causa raíz identificada» O se completó el campo «Causa raíz» Capturar Compare el campo de estado o compruebe si se completó el campo Tipo de evento inferred
	Incidente vinculado al problema	Acción de vincular un ticket de incidente relacionado con el registro de problema. Se registra 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 «Profundidad del vínculo entre incidentes y problemas» y para priorizar según el impacto en el negocio. Dónde obtenerlo Vínculos de incidencias de Jira: se creó un vínculo de tipo «causa» o «está relacionado con» Capturar Se registra cuando se crea un vínculo entre incidencias Tipo de evento explicit
	Investigación iniciada	Cambio del estado del problema a uno que indica que la investigación está activa, por ejemplo, «En investigación» o «En curso». Marca el inicio de la fase de trabajo activo.
Por qué es importante Inicia el cómputo del tiempo de ciclo de la investigación. Ayuda a distinguir el tiempo de espera en la lista de pendientes del tiempo dedicado al análisis. Dónde obtenerlo Historial de incidencias de Jira: el estado cambió a «En investigación» o «En curso» Capturar Compare las actualizaciones del campo de estado Tipo de evento inferred
	Registro de problema cerrado	Fin definitivo del ciclo de vida del problema. Se registra explícitamente cuando el estado cambia a «Cerrado».
Por qué es importante Fin 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: el estado cambió a «Cerrado» Capturar Se registra cuando el estado cambia a «Cerrado» Tipo de evento explicit
	Registro de problema creado	Evento inicial en el que se crea el ticket de problema en el sistema. Queda registrado 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 de historial: evento de creación de la incidencia Capturar Se registra cuando se confirma la transacción de creación de la incidencia Tipo de evento explicit
	Resolución verificada	Confirmación de que la solución resolvió el problema de forma eficaz. Se deduce de una transición de estado a «Resuelto» o a un estado específico de «Verificado».
Por qué es importante Control de calidad que garantiza que la solución funciona. Las demoras en esta etapa 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: el estado cambió a «Resuelto» o «Verificado» Capturar Compare las actualizaciones del campo de estado Tipo de evento inferred
	Solución temporal actualizada	Creació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 rapidez con que se ofrece un alivio al negocio. Es fundamental para el KPI «Tiempo de entrega de la solución temporal». Dónde obtenerlo Historial de incidencias de Jira: se modificó el campo «Solución temporal» (no es nulo) Capturar Se registra cuando se modifica el campo «Solución temporal» Tipo de evento explicit
	Prioridad del problema modificada	Actualización del campo de prioridad del registro de problema. Se registra mediante el seguimiento de los cambios en el campo «Prioridad» de la pestaña de historial.
Por qué es importante Indica que el problema se ha escalado o que se ha reducido su prioridad. Analizar este cambio ayuda a evaluar la precisión de la clasificación inicial y la antigüedad de los problemas de alta prioridad pendientes. Dónde obtenerlo Historial de incidencias de Jira: el campo «Prioridad» cambió del valor anterior al nuevo valor Capturar Se registra cuando se actualiza el campo de prioridad Tipo de evento explicit
	Problema reabierto	Transición del problema de un estado «Resuelto» o «Cerrado» a un estado activo. Indica que la solución ha fallado o que la resolución se ha rechazado.
Por qué es importante Es una métrica de calidad fundamental. Una tasa elevada de reaperturas indica un análisis de causas raíz o unas pruebas poco eficaces. Dónde obtenerlo Historial de incidencias de Jira: el estado cambió de «Cerrado»/«Resuelto» a «Abierto»/«En curso» Capturar Compare la secuencia del campo de estado Tipo de evento inferred
	Revisión posterior a la implementación	Realización de una revisión después de aplicar la solución. Se registra mediante un cambio de estado a «En revisión» o mediante actualizaciones de campos específicos de la revisión posterior a la implementación (PIR).
Por qué es importante Actividad de cumplimiento que garantiza que se documenten las lecciones aprendidas. Permite analizar el «Cumplimiento de la revisión posterior a la implementación». Dónde obtenerlo Historial de incidencias de Jira: el estado cambió a «En revisión» O se actualizó el campo «Notas de la PIR» Capturar Compare el campo de estado o las actualizaciones de los campos de la PIR Tipo de evento inferred
	SLA incumplido	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: «Tiempo hasta la resolución» > objetivo, o valor calculado Capturar Obtenga el dato del campo del SLA o compare la fecha de vencimiento con la fecha de resolución Tipo de evento calculated
	Solicitud de cambio vinculada	Vinculación de una solicitud de cambio (RFC) al registro de problema. Indica el inicio del proceso de solución definitiva.
Por qué es importante Mide el tiempo transcurrido entre la identificación de la causa y el inicio de las medidas correctivas. Permite analizar el KPI «Demora en la transición a la gestión de cambios». Dónde obtenerlo Vínculos de incidencias de Jira: se creó un vínculo de tipo «se corrige mediante» o se vinculó una incidencia de tipo «Cambio» Capturar Se registra cuando se crea un vínculo con una incidencia de tipo «Cambio» Tipo de evento explicit
	Solución definitiva aplicada	Transición que indica que se ha implementado la solución. Por lo general, se deduce de un cambio de estado a «En implementación» o «Corregido».
Por qué es importante Marca el fin del trabajo técnico de corrección. Se utiliza para medir el tiempo de ciclo de implementación. Dónde obtenerlo Historial de incidencias de Jira: el estado cambió a «Implementado», «Pendiente de verificación» o «Corregido» Capturar 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 gestión de problemas.
Vaya a la barra de menú superior y seleccione Filters. A continuación, haga clic en Advanced Issue Search para abrir el navegador de incidencias.
Cambie el modo de búsqueda a JQL (Jira Query Language) en lugar de Basic, si aún no está seleccionado.
Introduzca la consulta JQL específica que se indica en la sección Query para filtrar los registros de problemas (por ejemplo, project = 'Problem Management'). Compruebe que el intervalo de tiempo se ajuste a los límites de exportación del sistema.
Haga clic en el botón Search para verificar que la lista muestre los registros de problemas esperados.
Busque el botón Export en la esquina superior derecha de la interfaz del navegador de incidencias.
Seleccione Export XML en el menú desplegable. No seleccione CSV, ya que la exportación CSV estándar solo incluye los datos del estado actual y no contiene los registros históricos de cambios necesarios para Process Mining.
Guarde el archivo XML generado (por ejemplo, jira_export.xml) en un directorio local al que pueda acceder su entorno de procesamiento.
Prepare el entorno de Python e instale la biblioteca pandas si aún no está instalada.
Ejecute el script de Python indicado en la sección Query y compruebe que la variable de ruta del archivo coincida con la ubicación donde guardó el XML.
El script analiza la estructura RSS/XML y extrae la marca de tiempo 'Created', las entradas de 'History' sobre cambios de estado, prioridad y asignación, y los 'Issue Links' de incidentes relacionados.
El script calcula los incumplimientos de SLA comparando las fechas de resolución con las fechas límite y genera un Registro de eventos CSV con el formato adecuado para ProcessMind.

Configuración

Formato de exportación: Debe usar 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 limitarse 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: Compruebe que la clave project coincida con el identificador específico de su proyecto de gestión de problemas (por ejemplo, PROB, PM).
Zona horaria del sistema: Compruebe que el perfil de usuario que realiza la exportación use la misma zona horaria que el sistema para mantener la coherencia de las marcas de tiempo.
Permisos de campos: El usuario debe tener permiso para consultar el historial de cambios y las incidencias vinculadas, a fin de capturar las transiciones y los vínculos entre incidentes.
Campos personalizados: Si 'Root Cause' o 'Workaround' son campos personalizados, compruebe que la lógica de correspondencia de nombres de campo del script coincida con los nombres específicos de su instancia de Jira.

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

Preparación: Compruebe que tenga instalado Python 3.x y 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 token de acceso personal (PAT).
Identificación de los ID de campos personalizados: Jira Service Management asigna ID dinámicos a los campos personalizados (por ejemplo, customfield_10012 para Support Group o SLA). Antes de ejecutar la extracción principal, use un navegador o Postman para consultar una incidencia de problema específica (/rest/api/2/issue/[ISSUE-KEY]) e identificar los ID de los campos 'Support Group', 'Workaround', 'Root Cause' y los 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 ID reales de los campos personalizados identificados en el paso 2. Actualice JQL_QUERY para que se aplique 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 del flujo de trabajo de Jira (por ejemplo, 'Under Investigation', 'Implementing', 'Resolved') a los nombres de actividad estándar de ProcessMind (por ejemplo, 'Investigation Started', 'Permanent Fix Applied').
Ejecución de la extracción: Ejecute el script desde una terminal o un IDE. El script usa 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 todas las incidencias. 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 la lista de interés (Status, Priority, Link, etc.) y genera la fila de evento correspondiente.
Gestión de SLA: El script intenta detectar incumplimientos de SLA buscando cambios en campos personalizados relacionados con SLA o transiciones de estado que indiquen explícitamente 'Breached'. Ajuste la lógica de la función _parse_sla_breach si su sistema usa 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 el archivo y compruebe que los encabezados de columna coincidan con los requisitos de ProcessMind.
Carga en ProcessMind: Importe el archivo CSV en ProcessMind. Asigne ProblemKey a Case ID, ActivityName a Activity y EventTimestamp a Timestamp.

Configuración

Punto de conexión de la API: Usa /rest/api/2/search (compatible con Cloud y la mayoría de las versiones de Data Center). También admite la API v3, pero la v2 suele ofrecer mayor compatibilidad.
Paginación: El script pagina los resultados con startAt y maxResults para procesar conjuntos de datos grandes de forma eficiente. El tamaño predeterminado de cada lote es 50.
Ampliación del registro de cambios: 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.
Filtro JQL: La consulta filtra por issuetype = Problem. Se recomienda añadir un filtro de fechas (por ejemplo, created >= -180d) para limitar el volumen de datos durante las pruebas iniciales.
Autenticación: Admite autenticación básica (correo electrónico y token) para Cloud. En Data Center, modifique los encabezados para usar tokens Bearer.
Correspondencia de campos: Se requiere una configuración esencial. Los nombres internos de los campos 'Status' y 'Priority' de Jira son estándar, pero 'Support Group', 'Root Cause' y 'SLA' casi siempre son campos personalizados con ID únicos (por ejemplo, customfield_12345).

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}")

¿Todo listo para empezar?

Convierta hoy los datos de gestión de problemas en información útil para la acción. Descargue la guía o póngase en contacto con nuestro equipo de soporte para empezar a usar Process Mining.

Volver a la guía de mejora

Descargar Template

Optimice hoy el flujo de gestión de problemas

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

Comience su prueba gratuita

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

Su Template de datos para la gestión de problemas

Su Template 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 incidencias de Jira Service Management

Pasos

Configuración

Consulta de ejemplo sql

Extracción con Python mediante la API REST de Jira y el registro de cambios

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para empezar?

Optimice hoy el flujo de gestión de problemas