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

Su Template de datos para la gestión de solicitudes de servicio

Jira Service Management

Atributos de la gestión de solicitudes de servicio (17) Actividades de la gestión de solicitudes de servicio (13) Guías de extracción (3)

Su Template de datos para la gestión de solicitudes de servicio

Este Template ofrece un enfoque estructurado para recopilar los datos esenciales necesarios para analizar sus procesos de solicitudes de servicio. Detalla los atributos fundamentales que debe recopilar, las actividades clave que debe seguir y cómo extraer esta información de su sistema. Utilice este recurso para agilizar la preparación de sus datos y obtener una visión más profunda de sus operaciones.

Atributos recomendados para un análisis completo
Actividades clave que debe seguir para descubrir el proceso
Guía de extracción para Jira Service Management

¿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 solicitudes de servicio

Estos son los campos de datos recomendados para incluir en su registro de eventos y obtener un análisis completo de la gestión de solicitudes de servicio.

5 Obligatorio 5 Recomendado 7 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre del evento o la tarea específicos que tuvieron lugar durante el ciclo de vida de la solicitud de servicio.
Descripción Este atributo describe la acción específica o la transición de estado que tuvo lugar en un momento determinado para una solicitud de servicio. Algunos ejemplos son «Request Created», «Request Assigned», «Solution Implemented» y «Request Closed». El análisis de la secuencia y la frecuencia de estas actividades constituye la base de Process Mining. Permite visualizar mapas de procesos, identificar cuellos de botella y detectar desviaciones respecto al Workflow estándar, algo fundamental para comprender la eficiencia y el cumplimiento del proceso. Por qué es importante Define los pasos del proceso y permite visualizar el mapa de procesos, así como analizar los patrones y las desviaciones del Workflow. Dónde obtenerlo Normalmente se obtiene del historial de transiciones de «status» de una incidencia de Jira. Cada entrada del registro de cambios de la incidencia correspondiente al campo de estado representa una actividad. Ejemplos Solicitud sometida a triajeInformación solicitadaSolución implementadaSolicitud de servicio cerrada
	Hora de inicio EventTime	La fecha y hora exactas en que tuvo lugar una actividad o un evento específicos.
Descripción La hora de inicio, o marca de tiempo del evento, registra el momento exacto en que ocurrió una actividad. Es un componente fundamental de cualquier análisis de Process Mining, ya que proporciona el contexto temporal de todo el proceso. Esta marca de tiempo se utiliza para ordenar los eventos secuencialmente, calcular la duración entre actividades, medir los tiempos totales de ciclo de los casos y analizar el rendimiento del proceso frente a objetivos basados en el tiempo, como los SLA. Sin marcas de tiempo precisas, es imposible comprender el flujo del proceso, identificar retrasos o medir la eficiencia. Por qué es importante Esta marca de tiempo es esencial para ordenar eventos, calcular duraciones y tiempos de ciclo, e identificar cuellos de botella en el proceso. Dónde obtenerlo Es la marca de tiempo asociada a cada transición de estado en el registro de cambios de la incidencia de Jira. La hora de creación de la incidencia corresponde al campo «created». Ejemplos 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	ID de solicitud de servicio ServiceRequestId	El identificador único de cada solicitud de servicio, que actúa como clave principal de todos los eventos relacionados.
Descripción El ID de solicitud de servicio, denominado con frecuencia Issue Key en Jira, identifica de forma única cada solicitud de servicio individual enviada por un usuario o sistema. Actúa como hilo conductor central que vincula todos los eventos posteriores, desde el registro inicial hasta el cierre definitivo, lo que permite analizar de principio a fin el recorrido de cada solicitud de servicio. En Process Mining, este ID es esencial para correlacionar los casos. Garantiza que cada actividad, cambio de estado y marca de tiempo se asocie correctamente con la solicitud correspondiente y forme una instancia de proceso coherente para el análisis. Por qué es importante Este ID es el identificador fundamental del caso que conecta todas las actividades relacionadas en un único flujo de proceso de principio a fin, lo que hace posible el análisis del proceso. Dónde obtenerlo Este es el campo «key» de una incidencia en Jira Service Management. Ejemplos SR-2023-001IT-45892HELP-105
	Sistema de origen SourceSystem	El sistema del que se extrajeron los datos de la solicitud de servicio.
Descripción Este atributo identifica el origen de los datos, que en este caso es Jira Service Management. Aunque puede parecer poco relevante al analizar datos de una sola fuente, resulta fundamental al combinar datos de procesos procedentes de varios sistemas. Para el análisis, ayuda a rastrear el linaje de los datos y garantizar su calidad. También permite filtrar y comparar procesos que pueden abarcar distintas plataformas de software o interactuar con ellas. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos y para combinar datos de procesos procedentes de varios sistemas empresariales. Dónde obtenerlo Normalmente es un valor estático que se añade durante la extracción y transformación de datos para identificar el origen del conjunto de datos. Ejemplos Jira Service ManagementJiraSM
	Última actualización de datos LastDataUpdate	La marca de tiempo que indica cuándo se actualizaron por última vez los datos del sistema de origen.
Descripción Este atributo registra la fecha y hora de la extracción de datos más reciente de Jira Service Management. Proporciona un contexto fundamental sobre la actualidad del análisis y de los datos incluidos en los Dashboards y los KPI. En cualquier análisis, conocer la actualidad de los datos es esencial para tomar decisiones fundamentadas. Esta marca de tiempo ayuda a comprender si se está consultando información en tiempo real o una instantánea de un momento anterior, lo que afecta a la relevancia de las conclusiones. Por qué es importante Indica la actualidad de los datos y garantiza que los análisis se basen en información actualizada. Dónde obtenerlo Es un campo de metadatos generado y almacenado por la herramienta o el script de extracción de datos al finalizar su ejecución. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Estado de la solicitud RequestStatus	El estado actual de la solicitud de servicio dentro de su ciclo de vida.
Descripción Este atributo representa el estado actual de una solicitud de servicio, como «Open», «In Progress», «Waiting for Customer» o «Resolved». Proporciona una instantánea de la situación de la solicitud en un momento determinado. Aunque el registro de actividades muestra el flujo histórico, el estado actual resulta útil para analizar el trabajo pendiente e identificar elementos atascados. Por ejemplo, el análisis puede centrarse en solicitudes que llevan un tiempo inusualmente largo en el estado «Waiting for Vendor», lo que pone de manifiesto dependencias externas y retrasos. Por qué es importante Proporciona una instantánea actual de cada caso, lo que permite analizar el trabajo en curso e identificar solicitudes estancadas o antiguas. Dónde obtenerlo Es el campo «status» de una incidencia de Jira. Ejemplos AbiertoEn cursoPendiente del clienteResuelto
	Fecha límite del SLA SlaDueDate	La fecha y hora objetivo en que debería resolverse la solicitud de servicio según su SLA.
Descripción La fecha límite del SLA es una marca de tiempo calculada que representa el plazo para resolver una solicitud. Se determina según la prioridad y el tipo de solicitud, así como las políticas específicas del Acuerdo de Nivel de Servicio (SLA) configuradas en Jira Service Management. Este atributo es fundamental para el panel «Rendimiento de los SLA de las solicitudes de servicio» y el KPI «Tasa de cumplimiento de los SLA». Al comparar el tiempo real de resolución con esta fecha límite, el sistema puede determinar si cada solicitud se completó a tiempo, se completó tarde o corre el riesgo de incumplir su SLA. Por qué es importante Es el punto de referencia para medir el rendimiento. Contribuye directamente al cálculo del cumplimiento de los SLA y ayuda a priorizar el trabajo. Dónde obtenerlo Jira Service Management gestiona la información de los SLA, a la que se puede acceder mediante la API. A menudo se almacena en campos personalizados que se actualizan dinámicamente. Ejemplos 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Persona asignada Assignee	El usuario o agente asignado actualmente para trabajar en la solicitud de servicio.
Descripción La persona asignada es responsable de la siguiente acción o de resolver la solicitud de servicio. El valor de este atributo puede cambiar varias veces durante el ciclo de vida de la solicitud, a medida que esta pasa entre distintos agentes o equipos. Este atributo es fundamental para analizar la carga de trabajo, medir el rendimiento y gestionar los recursos. Permite filtrar el proceso por agente, comparar los tiempos de resolución entre personas e identificar posibles necesidades de formación o desequilibrios de carga que provoquen cuellos de botella. Por qué es importante Este atributo es esencial para analizar la carga de trabajo de los agentes, medir el rendimiento individual y comprender la asignación de recursos. Dónde obtenerlo Corresponde al campo «assignee» de una incidencia de Jira. Ejemplos Alice JohnsonBob WilliamsSin asignar
	Prioridad de la solicitud RequestPriority	El nivel de prioridad asignado a la solicitud de servicio, como baja, media, alta o crítica.
Descripción La prioridad de la solicitud indica la urgencia y el impacto empresarial de una solicitud de servicio. Esta clasificación determina el orden en que se gestionan las solicitudes y suele establecer los tiempos de resolución objetivo y los SLA. En el análisis de procesos, la prioridad es una dimensión clave para la segmentación. Permite comparar los tiempos de ciclo y el cumplimiento de los SLA entre distintos niveles de prioridad, y comprobar que las solicitudes de alta prioridad se procesan realmente más rápido y cumplen sus objetivos. Esto ayuda a validar la eficacia del sistema de priorización. Por qué es importante Permite segmentar el análisis para garantizar que las solicitudes de alta prioridad se gestionen con mayor rapidez y cumplan niveles de servicio más exigentes. Dónde obtenerlo Corresponde al campo «priority» de una incidencia de Jira. Ejemplos MáximaAltaMediaBaja
	Tipo de solicitud RequestType	La clasificación de la solicitud de servicio, como «Access Request» o «Hardware Issue».
Descripción Request Type clasifica la solicitud de servicio según su naturaleza. Es una dimensión fundamental para el análisis, ya que los distintos tipos de solicitud suelen tener procesos de resolución, SLA y necesidades de recursos diferentes. Al segmentar el análisis del proceso por Request Type, las organizaciones pueden adaptar las mejoras a flujos de trabajo específicos. Por ejemplo, el cuello de botella de una solicitud «Password Reset» será muy diferente del de una solicitud «New Server Provisioning». Este atributo es clave para crear Dashboards relevantes, como «Resolution Quality by Category». Por qué es importante Este atributo es esencial para comparar procesos, cargas de trabajo y rendimiento entre distintas categorías de solicitudes de servicio. Dónde obtenerlo A menudo corresponde al campo «issuetype» de Jira o a un campo personalizado «Request Type» de Jira Service Management. Ejemplos Solicitar una cuenta nuevaObtener ayuda de TIIncorporar a una persona empleada nueva
	¿Se reabrió? IsReopened	Un indicador booleano que señala si una solicitud de servicio se reabrió después de resolverse.
Descripción Este atributo calculado es un indicador verdadero/falso que se establece en verdadero si el Workflow de una solicitud incluye la actividad «Request Reopened». Se obtiene mediante el análisis de la secuencia de actividades de cada caso. Este indicador es esencial para calcular el KPI «Tasa de reapertura de solicitudes de servicio» y alimentar el panel «Volumen de solicitudes de servicio reabiertas». Una tasa de reapertura elevada indica claramente una baja calidad de resolución en el primer intento, lo que genera retrabajo y reduce la satisfacción del cliente. Analizar qué tipos de solicitudes o resoluciones se asocian con este indicador puede señalar áreas de mejora. Por qué es importante Mide directamente el retrabajo y la calidad de la resolución en el primer intento, indicadores clave de la eficacia del proceso y la satisfacción del cliente. Dónde obtenerlo Se calcula durante la transformación de datos comprobando si la secuencia de actividades de un caso contiene una transición «Reopened» posterior a una transición «Resolved». Ejemplos truefalse
	Canal Channel	El método de envío utilizado para crear la solicitud de servicio, como correo electrónico, portal o API.
Descripción El atributo de canal identifica cómo entró una solicitud de servicio en el sistema. Entre los canales habituales de Jira Service Management se encuentran el portal del cliente, el correo electrónico o la creación directa por parte de un agente. Analizar el proceso por canal es importante para comprender el comportamiento de los usuarios y optimizar la prestación del servicio. Puede revelar si las solicitudes procedentes de determinados canales tardan más en resolverse o requieren más aclaraciones, lo que podría indicar la necesidad de mejorar los formularios del portal o las reglas de análisis de correo electrónico. Esto respalda el panel «Tendencias del rendimiento de las solicitudes de servicio». Por qué es importante Ayuda a analizar si el canal de envío afecta a los tiempos de resolución, la claridad de las solicitudes o la eficiencia general del proceso. Dónde obtenerlo Esta información está disponible en Jira Service Management mediante el campo «Request channel type». Puede requerir acceso específico a la API o almacenarse en un campo personalizado. Ejemplos portalcorreo electrónicoAPI
	Equipo asignado AssignedTeam	El equipo o grupo responsable de gestionar la solicitud de servicio.
Descripción Este atributo especifica el equipo asignado a una solicitud, que suele ser una agrupación de nivel superior a la persona asignada. Resulta útil para analizar el rendimiento a nivel de equipo, por ejemplo, al comparar el equipo First-Level Support con el equipo Network Operations. Esta dimensión es fundamental para Dashboards como «Agent Workload and Resolution Metrics». Permite agregar las métricas de rendimiento a nivel de equipo, facilita comparaciones justas y ayuda a comprender cómo contribuyen los distintos equipos al proceso general de prestación del servicio. Por qué es importante Permite analizar el rendimiento y equilibrar la carga de trabajo a nivel de equipo o departamento, en lugar de hacerlo únicamente por agente. Dónde obtenerlo Puede ser un campo personalizado de Jira, por ejemplo, «Team», o derivarse de los atributos del perfil de usuario de la persona asignada. Ejemplos Soporte de TI - Nivel 1Equipo de infraestructuraSoporte de aplicaciones
	Estado del SLA SlaState	Indica si la solicitud de servicio cumplió el SLA definido, lo incumplió o aún se encuentra dentro de él.
Descripción El estado del SLA es un atributo calculado que categoriza cada solicitud de servicio según su rendimiento frente a la fecha límite del SLA. Sus posibles valores incluyen «Met», «Breached» o «In Progress». Se determina comparando la marca de tiempo de resolución con «SlaDueDate». Es el atributo principal del panel «Rendimiento de los SLA de las solicitudes de servicio» y se utiliza para calcular el KPI «Tasa de cumplimiento de los SLA». Proporciona una visión clara e inmediata del cumplimiento del nivel de servicio, algo fundamental para la elaboración de informes, la gestión de contratos y el mantenimiento de la calidad del servicio. Por qué es importante Proporciona un indicador claro e inmediato del rendimiento del SLA, una medida fundamental de la calidad del servicio y del cumplimiento contractual. Dónde obtenerlo Se calcula durante la transformación de datos. Si el tiempo de resolución es anterior a «SlaDueDate», el estado es «Met»; de lo contrario, es «Breached». Ejemplos CumplidoIncumplidoEn curso
	Informante Reporter	El usuario que creó o informó inicialmente de la solicitud de servicio.
Descripción El informante es la persona, a menudo un usuario final o cliente, que envió la solicitud de servicio. Este atributo identifica a la parte interesada que inició el proceso. En el análisis, el informante puede utilizarse para comprender los patrones de solicitud de distintos usuarios, departamentos o segmentos de clientes. Ayuda a responder preguntas como «¿Qué departamentos envían más solicitudes?» o «¿Hay usuarios concretos que se enfrentan repetidamente a los mismos problemas?». Esta información es valiosa para gestionar los problemas de forma proactiva y mejorar la formación de los usuarios. Por qué es importante Identifica a quien origina la solicitud y permite analizar el volumen y los tipos de solicitudes por usuario, departamento o cliente. Dónde obtenerlo Corresponde al campo «reporter» de una incidencia de Jira. Ejemplos Charles DarwinMarie CurieIsaac Newton
	Organización Organization	La organización del cliente o el departamento interno al que pertenece el informante.
Descripción Este atributo agrupa a los informantes por organizaciones o departamentos. Jira Service Management incluye una función integrada de «Organizations» que permite a los agentes gestionar solicitudes de varios clientes o equipos internos. El análisis por organización proporciona un contexto empresarial valioso. Puede ayudar a identificar qué clientes o departamentos consumen más recursos de soporte, si algún grupo concreto experimenta problemas recurrentes y si los SLA se cumplen de forma constante en las distintas unidades de negocio. Por qué es importante Facilita el análisis de la demanda y el rendimiento del servicio por cliente o departamento interno, y proporciona información empresarial clave. Dónde obtenerlo Estos datos proceden del campo «Organizations» asociado a la solicitud de servicio en Jira Service Management. Ejemplos Acme CorporationDepartamento de finanzasGlobal Tech Inc.
	Resolución Resolution	El resultado o desenlace final de una solicitud de servicio resuelta.
Descripción El campo de resolución indica por qué se cerró una solicitud de servicio. Algunos valores habituales son «Done», «Won't Do», «Duplicate» o «Cannot Reproduce». Proporciona detalles sobre el cierre más allá de un estado «Resolved» o «Closed». El análisis de las resoluciones ayuda a comprender la calidad y la naturaleza de los resultados. Por ejemplo, un número elevado de resoluciones «Duplicate» podría indicar un problema en el proceso de envío de solicitudes, mientras que analizar qué resoluciones dan lugar a solicitudes reabiertas puede revelar soluciones ineficaces. Por qué es importante Proporciona contexto sobre el resultado de una solicitud, ayuda a analizar la calidad de la resolución e identificar tendencias sobre los motivos por los que se cierran las solicitudes. Dónde obtenerlo Corresponde al campo «resolution» de una incidencia de Jira, que normalmente se establece cuando la incidencia pasa a una categoría de estado «done». Ejemplos CompletadoNo se haráDuplicadoCorregido

Obligatorio Recomendado Opcional

Actividades de la gestión de solicitudes de servicio

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

5 Recomendado 8 Opcional

	Actividad	Descripción
	Resolución propuesta	En muchos Workflows de mesas de servicio, este es un paso diferenciado en el que se ofrece una solución a quien realiza la solicitud para que la apruebe. Se infiere cuando el estado de la incidencia cambia a un estado como 'Pending Customer Acceptance' o 'Awaiting Confirmation'.
Por qué es importante Esta actividad aísla el tiempo dedicado a esperar los comentarios del cliente después de proporcionar una solución y ayuda a diferenciarlo del tiempo de trabajo interno. Dónde obtenerlo Se infiere del historial de la incidencia y se captura en la marca de tiempo en la que el estado cambia a un estado que indica que la solución está pendiente de validación por parte del cliente. Recopilar Identifique la marca de tiempo del cambio de estado a 'Pending Customer Acceptance' o su equivalente. Tipo de evento inferred
	Solicitud asignada	Esta actividad se produce cuando una solicitud de servicio se asigna a un agente o equipo específico para su resolución. Jira registra explícitamente los cambios en el campo 'Assignee', lo que proporciona una marca de tiempo clara del momento de la asignación.
Por qué es importante Este es un hito clave para medir el tiempo entre el triaje y la asignación, así como la distribución de la carga de trabajo de los agentes. Marca la transición de la cola a la gestión activa. Dónde obtenerlo Se captura en el historial de la incidencia buscando la primera ocasión en la que el campo 'Assignee' se establece o cambia desde un estado sin asignar. Recopilar Utilice la marca de tiempo del primer cambio del campo 'Assignee' en el historial de la incidencia. Tipo de evento explicit
	Solicitud de servicio cerrada	Representa el cierre administrativo final de la solicitud de servicio, que suele producirse automáticamente después de un periodo determinado en el estado 'Resolved'. Es el punto terminal del ciclo de vida de la incidencia en Jira.
Por qué es importante Este es el evento final definitivo del proceso. El tiempo entre 'Resolved' y 'Closed' puede analizarse para comprender la carga administrativa o las políticas de cierre automático. Dónde obtenerlo Se infiere del historial de la incidencia. La marca de tiempo corresponde al cambio de estado final a 'Closed' o a un estado terminal equivalente. Recopilar Identifique la marca de tiempo del cambio de estado final a un estado 'Closed'. Tipo de evento inferred
	Solicitud de servicio creada	Esta actividad marca el inicio del ciclo de vida de la solicitud de servicio, cuando un usuario envía formalmente una solicitud a través de un portal, correo electrónico u otro canal. Este evento se captura explícitamente en Jira cuando se crea una incidencia nueva de tipo 'Service Request', registrando la marca de tiempo de creación.
Por qué es importante Este es el evento de inicio principal del proceso. Es esencial para calcular el tiempo de ciclo total y comprender el volumen y los patrones de llegada de las solicitudes. Dónde obtenerlo Este es un evento explícito capturado en la tabla del historial de la incidencia. La marca de tiempo de la actividad corresponde al campo 'created' de la incidencia de Jira. Recopilar Utilice la marca de tiempo de creación de la incidencia de la tabla 'issues' o del historial. Tipo de evento explicit
	Solicitud de servicio resuelta	Marca el momento oficial en que la solicitud se considera atendida y la solución queda registrada. Jira completa el campo 'Resolution Date' cuando una incidencia entra por primera vez en un estado de la categoría 'Done'.
Por qué es importante Este es un hito final principal del proceso, fundamental para calcular el tiempo de resolución y el cumplimiento de los SLA. Señala el final del trabajo activo. Dónde obtenerlo Este es un evento explícito. La marca de tiempo es el valor del campo 'Resolution Date' de la incidencia de Jira, que se establece en la primera transición a un estado de la categoría 'Done'. Recopilar Utilice el campo 'resolutiondate' de la incidencia de Jira. Este campo se completa automáticamente. Tipo de evento explicit
	Fin de la colaboración con el proveedor	Representa el momento en que el proveedor externo ha completado su acción y la solicitud de servicio vuelve al equipo interno. Se infiere cuando la incidencia sale del estado 'Waiting for vendor'.
Por qué es importante Medir la duración de la colaboración con el proveedor ayuda a gestionar su rendimiento y a comprender el impacto de terceros en los tiempos generales de resolución. Dónde obtenerlo Se infiere del historial de la incidencia. La marca de tiempo corresponde al momento en que el estado de la incidencia cambia de un estado de 'vendor' a un estado 'In Progress'. Recopilar Identifique la marca de tiempo en la que el campo 'status' cambia de un estado de 'vendor' a un estado activo. Tipo de evento inferred
	Información proporcionada	Se produce cuando quien realiza la solicitud responde con la información necesaria, lo que permite al agente reanudar el trabajo. Se infiere cuando la incidencia sale del estado 'Waiting for customer', a menudo después de que quien realiza la solicitud añada un comentario.
Por qué es importante Esta actividad completa el ciclo de solicitud y respuesta con el cliente. El tiempo transcurrido entre solicitar y recibir la información es un componente clave del tiempo de espera del proceso. Dónde obtenerlo Se infiere del historial de la incidencia. La marca de tiempo corresponde al momento en que el estado de la incidencia cambia de 'Waiting for customer' a un estado 'In Progress'. Recopilar Identifique la marca de tiempo en la que el campo 'status' cambia de un estado de espera a un estado activo. Tipo de evento inferred
	Información solicitada	Marca el momento en que un agente necesita más información de quien realiza la solicitud para continuar con la resolución. Normalmente se infiere cuando la incidencia pasa a un estado como 'Waiting for customer' o 'Pending Input'.
Por qué es importante Los ciclos frecuentes o prolongados de 'Information Requested' pueden indicar envíos iniciales poco claros o una comunicación ineficiente, y representan una fuente importante de retrasos. Dónde obtenerlo Se infiere del historial de la incidencia. La marca de tiempo corresponde al momento en que el estado de la incidencia cambia a 'Waiting for customer' o a un estado equivalente. Recopilar Identifique la marca de tiempo en la que el campo 'status' cambia a un valor que indica que el proceso está esperando al cliente. Tipo de evento inferred
	Inicio de la colaboración con el proveedor	Esta actividad indica que la solicitud de servicio se ha escalado a un proveedor externo o tercero, o que requiere una acción por su parte. Se infiere cuando la incidencia pasa a un estado como 'Waiting for vendor' o 'With Third Party'.
Por qué es importante Realizar el seguimiento de la colaboración con proveedores es fundamental para identificar dependencias externas y retrasos que están fuera del control directo de la mesa de servicio interna. Dónde obtenerlo Se infiere del historial de la incidencia. La marca de tiempo corresponde al momento en que el estado de la incidencia cambia a un estado designado de 'vendor'. Recopilar Identifique la marca de tiempo en la que el campo 'status' cambia a un valor como 'Waiting for Vendor'. Tipo de evento inferred
	Resolución confirmada	Se produce cuando quien realiza la solicitud acepta formalmente la solución propuesta, lo que suele activar una transición automática al estado 'Resolved'. Normalmente, este evento se infiere a partir de dicho cambio de estado.
Por qué es importante Este hito valida la eficacia de la solución y activa la detención del reloj del SLA. Ayuda a medir el tiempo que tardan los clientes en confirmar las correcciones. Dónde obtenerlo Se infiere del historial de la incidencia. La marca de tiempo corresponde al cambio de estado de 'Pending Customer Acceptance' a 'Resolved' o 'Closed'. Recopilar Identifique la marca de tiempo del cambio de estado de 'Pending Customer Acceptance' a un estado 'Resolved' o 'Closed'. Tipo de evento inferred
	Solicitud reabierta	Esta actividad captura los casos en los que una solicitud de servicio previamente resuelta vuelve a un estado activo. Se infiere mediante un cambio de estado desde un estado resuelto o cerrado a un estado abierto o en curso.
Por qué es importante Realizar el seguimiento de las solicitudes reabiertas es fundamental para medir la calidad de la resolución y la tasa de resolución en el primer contacto. Una tasa elevada de reapertura indica soluciones ineficaces o problemas recurrentes. Dónde obtenerlo Se infiere del historial de la incidencia al identificar una transición de estado desde un estado de categoría 'Resolved' o 'Closed' a un estado de categoría 'Open' o 'In Progress'. Recopilar Busque un cambio de estado desde una categoría 'Done' a una categoría 'To Do' o 'In Progress'. Tipo de evento inferred
	Solicitud sometida a triaje	Representa la evaluación inicial de una solicitud de servicio, en la que se determinan su prioridad, categoría e impacto. Esta actividad suele inferirse a partir de un cambio de estado, como pasar de 'New' a 'In Progress', o de un estado específico de 'Triaged'.
Por qué es importante Analizar el tiempo hasta el triaje ayuda a evaluar la eficiencia del proceso inicial de gestión de solicitudes. Los retrasos en esta fase pueden afectar significativamente a los tiempos generales de resolución y al cumplimiento de los SLA. Dónde obtenerlo Se infiere del historial de la incidencia al identificar la primera marca de tiempo de un cambio de estado desde un estado inicial 'New' u 'Open' a un estado activo como 'In Progress'. Recopilar Identifique el primer cambio de estado desde 'New' o desde un estado inicial equivalente, según el Workflow del proyecto. Tipo de evento inferred
	Solución implementada	Indica que el agente ha realizado las acciones necesarias o ha desarrollado una solución para abordar la solicitud de servicio. A menudo se infiere a partir de un cambio de estado a 'Pending Review' o directamente a 'Resolved'.
Por qué es importante Este hito marca la finalización del trabajo principal de resolución. El tiempo previo a esta actividad suele representar la parte del proceso que aporta el mayor valor. Dónde obtenerlo Se infiere del historial de la incidencia y corresponde a la marca de tiempo del cambio de estado a 'Resolved', 'Pending Acceptance' o un estado similar previo al cierre. Recopilar Identifique la marca de tiempo en la que el campo 'status' cambia a un valor que indica que el trabajo ha finalizado. 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 y vaya al menú principal.
Seleccione Filtros y, a continuación, elija Búsqueda avanzada de incidencias. Se abrirá el Navegador de incidencias, donde podrá crear consultas.
En la barra de búsqueda, introduzca la consulta JQL (Jira Query Language) proporcionada en la sección Consulta para filtrar las solicitudes de servicio específicas que desea analizar. Ajuste la clave del proyecto y el intervalo de fechas según sea necesario.
Haga clic en el botón Buscar para ejecutar la consulta. Revise la lista de incidencias devuelta para confirmar que corresponde al conjunto de datos correcto.
En la esquina superior derecha de la página de resultados, haga clic en el icono Exportar (normalmente tiene el aspecto de un cuadro con una flecha hacia fuera).
En el menú desplegable, seleccione XML. Es fundamental utilizar XML, ya que la exportación CSV estándar no contiene el historial detallado de cambios necesario para generar un registro de eventos completo.
Guarde el archivo XML descargado en su sistema local. Este archivo contiene todas las incidencias de la consulta, con su historial completo de cambios incluido en los datos de cada incidencia.
Como el XML exportado no tiene formato de registro de eventos, es necesario realizar un procesamiento posterior. Utilice un script, por ejemplo, en Python, Powershell u otro lenguaje, para analizar el archivo XML.
El script debe recorrer cada incidencia del archivo y crear un evento «Solicitud de servicio creada» a partir de la marca de tiempo de creación. Después, debe analizar el historial de cambios de cada incidencia e identificar los cambios en los campos «status» y «assignee» que correspondan a las actividades necesarias. Debe generar una fila nueva para cada cambio identificado.
El script debe transformar estos datos en un archivo CSV plano, con columnas para ServiceRequestId, ActivityName, EventTime y todos los demás atributos necesarios y recomendados.
El resultado final del script es el registro de eventos. Guarde este archivo CSV y prepárelo para cargarlo en la herramienta de Process Mining.

Configuración

Filtro de proyecto JQL: Utilice project = "[Your JSM Project Key]" para seleccionar el proyecto específico de gestión de servicios. Sustituya el marcador de posición por la clave de su proyecto, por ejemplo, «JSM» o «HELPDESK».
Filtro de tipo de incidencia JQL: Utilice issuetype = "Service Request" o el nombre específico del tipo de incidencia utilizado para las solicitudes de servicio en su configuración.
Intervalo de fechas: Se recomienda encarecidamente filtrar por un periodo concreto para controlar el tamaño de la exportación. Utilice una cláusula como created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Un intervalo de 3 a 6 meses suele ser un buen punto de partida.
Formato de exportación: Debe seleccionar XML para la exportación. El formato CSV no incluye los datos del historial de cambios necesarios para crear el registro de eventos.
Permisos de Jira: La persona que realice la exportación debe tener el permiso «Browse Projects» para el proyecto de Jira especificado, a fin de consultar y exportar las incidencias.
Volumen de datos: La exportación predeterminada de la interfaz de Jira suele limitarse a 1.000 incidencias por vez. Si su consulta devuelve más resultados, debe exportar los datos en lotes más pequeños reduciendo el intervalo de fechas de cada exportación.

a Consulta de ejemplo config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Pasos

Obtenga acceso a la base de datos: Consiga credenciales de solo lectura y los datos de conexión (nombre de host, puerto y nombre de la base de datos) para la base de datos SQL de backend de la instancia de Jira. Normalmente necesitará la ayuda de una persona administradora de bases de datos o del departamento de TI.
Identifique el esquema de Jira: Conéctese a la base de datos mediante un cliente SQL como DBeaver, SQuirreL SQL o SQL Server Management Studio. Familiarícese con las tablas principales: jiraissue (datos principales de las incidencias), changegroup (historial de cambios), changeitem (detalles de cada cambio), project (detalles del proyecto), issuetype y priority.
Localice los identificadores de los campos personalizados: Atributos como RequestType y SlaDueDate suelen ser campos personalizados. Identifique sus identificadores consultando la tabla customfield: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Anote estos identificadores para utilizarlos en la consulta principal.
Personalice la consulta SQL: Copie el script SQL proporcionado en su cliente SQL. Debe sustituir cuidadosamente todos los valores de marcador de posición, incluidos entre corchetes, por los valores reales de su configuración de Jira. Esto incluye las claves de proyecto, los nombres de tipos de incidencia, los nombres de estados y los identificadores de campos personalizados.
Defina el intervalo de fechas: Localice la cláusula WHERE i.created >= '[YYYY-MM-DD]' en la sección inicial issue_base de la consulta. Modifique la fecha para definir el periodo de extracción de sus datos.
Ejecute la consulta: Ejecute el script SQL modificado. La consulta está diseñada para funcionar en bases de datos SQL habituales, como PostgreSQL, SQL Server y MySQL. En instancias grandes de Jira, puede tardar varios minutos.
Revise los resultados: Cuando termine la consulta, inspeccione brevemente la salida para confirmar que devuelve filas y que columnas como ServiceRequestId, ActivityName y EventTime contienen los valores esperados.
Exporte los datos: Exporte el conjunto completo de resultados desde su cliente SQL a un archivo CSV. Asigne al archivo un nombre descriptivo, como jira_servicerequest_eventlog.csv.
Prepárelo para la carga: Abra el archivo CSV y compruebe que los encabezados de columna coinciden exactamente con los nombres de atributos necesarios, por ejemplo, ServiceRequestId, ActivityName y EventTime. Asegúrese de guardar el archivo con codificación UTF-8 para garantizar la compatibilidad con ProcessMind.

Configuración

Requisitos previos: Se requiere acceso directo y de solo lectura a la base de datos de producción o réplica de Jira. El acceso estándar a la aplicación no es suficiente. También necesitará conocer a fondo el Workflow de su proyecto específico de Service Desk, incluidos los nombres exactos de los estados, tipos de incidencia y campos personalizados.
Filtros clave de la consulta: La consulta debe configurarse para seleccionar el conjunto de datos correcto. Preste especial atención a estas cláusulas WHERE:
- p.pkey IN ('[Your Project Key]'): Este es el filtro más importante. Limita los datos a uno o varios proyectos específicos de Jira Service Management.
- it.pname = '[Your Service Request Issue Type]': Garantiza que solo se extraigan solicitudes de servicio y no incidentes, problemas u otros tipos de incidencia.
- i.created >= '[YYYY-MM-DD]': Este filtro establece la fecha de inicio de la extracción. Para un análisis inicial, se recomienda un intervalo de los últimos 3 a 6 meses.
Asignación de estados del Workflow: La precisión del registro de eventos depende por completo de que los nombres de los estados de Jira estén correctamente asignados en la consulta. Debe sustituir marcadores como [Status for Triage], [Waiting for Customer Status] y [Resolved Status] por los nombres utilizados en su Workflow específico.
Consideraciones de rendimiento: Ejecutar esta consulta directamente en una base de datos de Jira grande y activa puede consumir muchos recursos y afectar potencialmente al rendimiento de la aplicación. Se recomienda encarecidamente realizar la extracción en una base de datos réplica de solo lectura o durante periodos de baja actividad.

a Consulta de ejemplo sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Pasos

Requisitos previos y configuración: Asegúrese de tener Python 3.6 o una versión posterior instalada en su sistema. Instale las bibliotecas de Python necesarias ejecutando el siguiente comando en su terminal: pip install requests pandas.
Genere un token de API de Jira: Inicie sesión en su cuenta de Jira Cloud. Vaya a la configuración de su perfil, seleccione «Account settings», abra la pestaña «Security» y cree un token de API. Cópielo y guárdelo de forma segura, ya que se utilizará para la autenticación.
Identifique los identificadores de campos personalizados: Muchos atributos de Jira, como «Request Type» o «SLA Due Date», son campos personalizados. Para encontrar sus identificadores, vaya a «Settings» > «Issues» > «Custom fields». Busque el campo que necesita y haga clic en los tres puntos «...» > «View field information». El identificador aparecerá en la URL, por ejemplo, customFieldId=10021. Anote estos identificadores para configurar el script.
Configure el script de Python: Abra el script de Python proporcionado en un editor de texto. Complete las variables de configuración situadas al principio del archivo, incluidas JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, la consulta jql_query para seleccionar sus solicitudes de servicio y los CUSTOM_FIELD_IDS identificados en el paso anterior.
Asigne los estados de Jira a las actividades: Revise detenidamente el diccionario STATUS_ACTIVITY_MAP del script. Debe actualizar esta asignación para que coincida con el Workflow específico de Jira Service Management. Las claves deben ser los nombres exactos de sus estados de Jira, por ejemplo, «Waiting for customer», y los valores deben ser los nombres de actividad correspondientes requeridos por el registro de eventos, por ejemplo, «Information Requested».
Ejecute el script de extracción: Abra un terminal o símbolo del sistema, vaya al directorio donde guardó el script y ejecútelo con el comando: python jira_extraction_script.py. El script se conectará a la API de Jira, obtendrá los datos de las incidencias, los procesará y mostrará el progreso en la consola.
Revise el archivo de salida: Cuando termine el script, generará un archivo CSV llamado jira_event_log.csv en el mismo directorio. Abra este archivo en una aplicación de hojas de cálculo para verificar su contenido. Compruebe que todas las columnas estén presentes y contengan los valores esperados.
Prepare la carga en ProcessMind: Asegúrese de que los encabezados de columna del archivo CSV coincidan exactamente con estos requisitos: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType y SlaDueDate. El archivo ya estará listo para cargarlo en ProcessMind.

Configuración

Autenticación de Jira: El script requiere la URL del dominio de Jira, la dirección de correo electrónico asociada a su cuenta de Jira y un token de API personal para acceder de forma segura.
Consulta JQL (jql_query): Este es el filtro principal de la extracción. Es fundamental definir una consulta JQL precisa para seleccionar las incidencias correctas. Recomendamos filtrar por project, issuetype y un intervalo de fechas concreto mediante createdDate para controlar el volumen de datos, por ejemplo, project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Asignación de estados a actividades (STATUS_ACTIVITY_MAP): Este diccionario es esencial para convertir correctamente los cambios de estado de Jira en actividades de proceso significativas. Debe personalizar esta asignación para reflejar el Workflow específico de su organización en Jira. Se ignorará cualquier estado que no figure en este mapa.
Identificadores de campos personalizados (CUSTOM_FIELD_IDS): Para extraer datos de campos personalizados como «Request Type» o «SLA Due Date», debe proporcionar sus identificadores únicos del sistema, por ejemplo, customfield_10021. Debe configurarlos correctamente para que se rellenen los atributos.
Intervalo de fechas y rendimiento: Para las extracciones iniciales, se recomienda utilizar un intervalo JQL de 3 a 6 meses para mantener un rendimiento controlable. La extracción de varios años de datos puede ser lenta debido a la paginación de la API y a los límites de frecuencia.

a Consulta de ejemplo python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        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'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

¿Listo para comenzar?

Utilice este Template para iniciar su recorrido de Process Mining y lograr mejoras significativas en la gestión de sus solicitudes de servicio. Comience a optimizar sus operaciones hoy mismo.

Volver a la guía de mejora Descargar Template

Optimice ahora la gestión de solicitudes de servicio en Jira

Alcance un 70 % de automatización y ponga fin a las demoras en la atención. ¡Aumente la eficiencia ahora!

Iniciar la prueba gratuita

No necesita tarjeta de crédito. La configuración solo tarda unos minutos.

Su Template de datos para la gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

Exportación integrada de CSV/XML de Jira Service Management

Pasos

Configuración

a Consulta de ejemplo config

Consulta directa a la base de datos en Jira Server/Data Center

Pasos

Configuración

a Consulta de ejemplo sql

Extracción mediante script de Python a través de la API REST de Jira Cloud

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice ahora la gestión de solicitudes de servicio en Jira

Su Template de datos para la gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

Exportación integrada de CSV/XML de Jira Service Management

Pasos

Configuración

a Consulta de ejemplo config

Consulta directa a la base de datos en Jira Server/Data Center

Pasos

Configuración

a Consulta de ejemplo sql

Extracción mediante script de Python a través de la API REST de Jira Cloud

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice ahora la gestión de solicitudes de servicio en Jira

Valoramos su privacidad