> 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 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 una estructura para recopilar los datos esenciales que necesita para analizar los procesos de solicitudes de servicio. Describe los atributos clave que debe recopilar y las actividades que conviene seguir, además de explicar cómo extraer esta información de su sistema. Utilice este recurso para agilizar la preparación de los datos y obtener una visión más clara de sus operaciones.

Atributos recomendados para un análisis completo
Actividades clave para descubrir el proceso
Guía para extraer datos de Jira Service Management

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

Descargar Template

Atributos de la gestión de solicitudes de servicio

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar en profundidad la gestión de solicitudes de servicio.

5 Obligatorio 5 Recomendado 7 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento o la tarea que tuvo lugar durante el ciclo de vida de la solicitud de servicio.
Descripción Este atributo describe la acción o transición de estado que tuvo lugar en un momento determinado durante una solicitud de servicio. Algunos ejemplos son «Solicitud creada», «Solicitud asignada», «Solución implementada» y «Solicitud cerrada». Analizar la secuencia y la frecuencia de estas actividades es fundamental en Process Mining. Permite visualizar los mapas de procesos, identificar cuellos de botella y detectar desviaciones del flujo de trabajo estándar, algo esencial 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 y analizar los patrones y las desviaciones del flujo de trabajo. Dónde obtenerlo Por lo general, se obtiene del historial de transiciones del campo «status» de una incidencia de Jira. Cada entrada del registro de cambios de la incidencia para el campo de estado representa una actividad. Ejemplos Solicitud clasificadaInformación solicitadaSolución implementadaSolicitud de servicio cerrada
	Hora de inicio EventTime	Fecha y hora exactas en que tuvo lugar una actividad o un evento.
Descripción La hora de inicio, o marca de tiempo del evento, registra el momento exacto en que ocurrió una actividad. Es un componente esencial de cualquier análisis de Process Mining, ya que aporta el contexto temporal de todo el proceso. Esta marca de tiempo permite ordenar los eventos, calcular la duración entre actividades y el tiempo de ciclo total de cada caso, y analizar el rendimiento del proceso frente a objetivos temporales como los SLA. Sin marcas de tiempo precisas, es imposible comprender el flujo del proceso, identificar demoras o medir la eficiencia. Por qué es importante Esta marca de tiempo es esencial para ordenar los 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 se encuentra en el campo «created». Ejemplos 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	ID de la solicitud de servicio ServiceRequestId	Identificador único de cada solicitud de servicio, que funciona como clave principal de todos los eventos relacionados.
Descripción El ID de la solicitud de servicio, conocido también como clave de incidencia en Jira, identifica de forma única cada solicitud de servicio enviada por un usuario o sistema. Es el hilo central que conecta todos los eventos posteriores, desde el registro inicial hasta el cierre definitivo, y permite analizar de principio a fin el recorrido de cada solicitud. En Process Mining, este ID es esencial para relacionar los casos. Garantiza que cada actividad, cambio de estado y fecha y hora se asocie correctamente con la solicitud correspondiente, y así conforma una instancia de proceso coherente para el análisis. Por qué es importante Este ID es el identificador fundamental del caso: conecta todas las actividades relacionadas en un único flujo de proceso de principio a fin y hace posible analizarlo. Dónde obtenerlo Es el campo «key» de una incidencia en Jira Service Management. Ejemplos SR-2023-001IT-45892HELP-105
	Sistema de origen SourceSystem	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 pueda parecer un detalle menor 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 abarcan o conectan distintas plataformas de software. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de los datos y para combinar datos de procesos de varios sistemas empresariales. Dónde obtenerlo Suele ser un valor estático que se añade durante la extracción y transformación de los datos para indicar el origen del conjunto de datos. Ejemplos Jira Service ManagementJiraSM
	Última actualización de los datos LastDataUpdate	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 más reciente de datos de Jira Service Management. Aporta contexto esencial sobre la actualidad del análisis y de los datos incluidos en los Dashboards y los KPI. Para tomar decisiones fundamentadas, es esencial saber cuándo se actualizaron los datos. Esta marca de tiempo ayuda a determinar si se está consultando información en tiempo real o una instantánea anterior, lo que influye en la relevancia de las conclusiones. Por qué es importante Indica la actualidad de los datos y permite comprobar que los análisis se basen en información actualizada. Dónde obtenerlo Es un campo de metadatos que la herramienta o el script de extracción de datos genera y almacena al finalizar la ejecución. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Estado de la solicitud RequestStatus	Estado actual de la solicitud de servicio en su ciclo de vida.
Descripción Este atributo representa el estado actual de una solicitud de servicio, por ejemplo, «Abierta», «En curso», «En espera del cliente» o «Resuelta». Ofrece una instantánea del estado de la solicitud en un momento determinado. El registro de actividades muestra el flujo histórico, mientras que el estado actual permite analizar el trabajo pendiente e identificar solicitudes estancadas. Por ejemplo, el análisis puede centrarse en las solicitudes que llevan un tiempo inusualmente largo en el estado «En espera del proveedor», lo que pone de manifiesto dependencias externas y demoras. Por qué es importante Ofrece una instantánea del estado actual de cada caso, lo que permite analizar el trabajo en curso e identificar solicitudes estancadas o atrasadas. Dónde obtenerlo Es el campo «status» de una incidencia de Jira. Ejemplos AbiertaEn cursoPendiente del clienteResuelta
	Fecha límite del SLA SlaDueDate	Fecha y hora objetivo en que debería resolverse la solicitud de servicio según el 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 Dashboard «Rendimiento del SLA de las solicitudes de servicio» y el KPI «Tasa de cumplimiento del 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, con retraso o si corre el riesgo de incumplir el SLA. Por qué es importante Es el valor de referencia para medir el rendimiento. Permite calcular directamente el cumplimiento del SLA y ayuda a priorizar el trabajo. Dónde obtenerlo Jira Service Management gestiona la información del SLA y permite acceder a ella 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	Usuario o agente asignado actualmente para atender 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 de un agente o equipo a otro. 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 y detectar posibles necesidades de formación o desequilibrios en la carga de trabajo 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	Nivel de prioridad asignado a la solicitud de servicio, por ejemplo, bajo, medio, alto o crítico.
Descripción La prioridad de la solicitud indica su urgencia y su impacto en el negocio. Esta clasificación determina el orden de atención 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 segmentar los datos. Permite comparar los tiempos de ciclo y el cumplimiento de los SLA entre distintos niveles de prioridad, y comprobar que las solicitudes prioritarias se procesen más rápido y cumplan sus objetivos. Así se puede validar la eficacia del sistema de priorización. Por qué es importante Permite segmentar el análisis para comprobar que las solicitudes prioritarias se atiendan más rápido 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	Clasificación de la solicitud de servicio, por ejemplo, «Solicitud de acceso» o «Problema de hardware».
Descripción El tipo de solicitud clasifica las solicitudes 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 tipo de solicitud, las organizaciones pueden adaptar las mejoras a flujos de trabajo específicos. Por ejemplo, el cuello de botella de una solicitud de «Restablecimiento de contraseña» será muy distinto del de una solicitud de «Aprovisionamiento de un servidor nuevo». Este atributo es clave para crear Dashboards relevantes, como «Calidad de la resolución por categoría». Por qué es importante Este atributo es esencial para comparar los procesos, la carga de trabajo y el rendimiento de distintas categorías de solicitudes de servicio. Dónde obtenerlo A menudo corresponde al campo «issuetype» de Jira o a un campo personalizado «Tipo de solicitud» de Jira Service Management. Ejemplos Solicitar una cuenta nuevaSolicitar ayuda de TIIncorporar a una persona nueva
	Canal Channel	Medio utilizado para crear la solicitud de servicio, como el correo electrónico, el portal o la API.
Descripción El atributo de canal identifica cómo llegó una solicitud de servicio al sistema. Entre los canales habituales de Jira Service Management se encuentran el portal del cliente, el correo electrónico y 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 recibidas por ciertos 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 del correo electrónico. Esto permite crear el Dashboard «Tendencias del volumen de solicitudes de servicio». Por qué es importante Ayuda a analizar si el canal de envío influye en 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 estar almacenada en un campo personalizado. Ejemplos portalcorreo electrónicoapi
	Equipo asignado AssignedTeam	Equipo o grupo responsable de atender la solicitud de servicio.
Descripción Este atributo especifica el equipo asignado a una solicitud, que suele ser un grupo más amplio que el de la persona asignada. Permite analizar el rendimiento de cada equipo, por ejemplo, comparar el equipo de soporte de primer nivel con el de operaciones de red. Esta dimensión es fundamental para Dashboards como «Carga de trabajo de los agentes y métricas de resolución». Permite agregar las métricas de rendimiento por equipo, facilita comparaciones equitativas y ayuda a comprender cómo contribuye cada equipo a la prestación general del servicio. Por qué es importante Permite analizar el rendimiento y equilibrar la carga de trabajo por equipo o departamento, en lugar de hacerlo únicamente por agente. Dónde obtenerlo Puede ser un campo personalizado de Jira (por ejemplo, «Equipo») 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ó, incumplió o sigue dentro del SLA establecido.
Descripción El estado del SLA es un atributo calculado que clasifica cada solicitud de servicio según su rendimiento frente a la fecha límite del SLA. Entre los valores posibles se encuentran «Cumplido», «Incumplido» y «En curso». Se determina comparando la marca de tiempo de resolución con «SlaDueDate». Es el atributo principal del Dashboard «Rendimiento del SLA de las solicitudes de servicio» y se utiliza para calcular el KPI «Tasa de cumplimiento del SLA». Ofrece una visión clara e inmediata del cumplimiento de los niveles de servicio, fundamental para la elaboración de informes, la gestión de contratos y el mantenimiento de la calidad del servicio. Por qué es importante Ofrece 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 los datos. Si el tiempo de resolución es anterior a «SlaDueDate», el estado es «Cumplido»; de lo contrario, es «Incumplido». Ejemplos CumplidoIncumplidoEn curso
	Informante Reporter	Usuario que creó o informó inicialmente 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 quien inició el proceso. En el análisis, el informante permite 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 inició 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	Organización del cliente o departamento interno al que pertenece el informante.
Descripción Este atributo agrupa a los informantes por organización o departamento. Jira Service Management incluye la función «Organizaciones», que permite a los agentes gestionar solicitudes de varios clientes o equipos internos. El análisis por organización aporta un contexto empresarial valioso. Puede ayudar a identificar qué clientes o departamentos consumen más recursos de soporte, si determinados grupos sufren problemas recurrentes y si los SLA se cumplen de forma sistemática en las distintas unidades de negocio. Por qué es importante Facilita el análisis de la demanda de servicio y del rendimiento por cliente o departamento interno, y aporta información empresarial clave. Dónde obtenerlo Estos datos proceden del campo «Organizaciones» asociado a la solicitud de servicio en Jira Service Management. Ejemplos Acme CorporationDepartamento de FinanzasGlobal Tech Inc.
	Resolución Resolution	Resultado o conclusión 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 «Hecho», «No se realizará», «Duplicado» o «No se puede reproducir». Aporta detalles sobre el cierre que van más allá de los estados «Resuelto» o «Cerrado». Analizar las resoluciones ayuda a comprender la calidad y la naturaleza de los resultados. Por ejemplo, un número elevado de resoluciones «Duplicado» podría indicar un problema en el proceso de envío de solicitudes. Por otra parte, hacer un seguimiento de las resoluciones que dan lugar a solicitudes reabiertas puede revelar soluciones ineficaces. Por qué es importante Aporta contexto sobre el resultado de una solicitud y ayuda a analizar la calidad de la resolución e identificar tendencias en los motivos de cierre. Dónde obtenerlo Corresponde al campo «resolution» de una incidencia de Jira, que suele establecerse cuando la incidencia pasa a un estado de la categoría «Hecho». Ejemplos HechoNo se realizaráDuplicadoCorregido
	Se reabrió IsReopened	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 flujo de trabajo de una solicitud incluye la actividad «Solicitud reabierta». Se obtiene al analizar 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 Dashboard «Volumen de solicitudes de servicio reabiertas». Una tasa de reapertura elevada suele indicar 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 permite identificar áreas de mejora. Por qué es importante Mide directamente el retrabajo y la calidad de resolución en el primer intento, dos indicadores clave de la eficacia del proceso y la satisfacción del cliente. Dónde obtenerlo Se calcula durante la transformación de los datos, comprobando si la secuencia de actividades de un caso contiene una transición «Reabierta» posterior a una transición «Resuelta». Ejemplos truefalse

Obligatorio Recomendado Opcional

Actividades de gestión de solicitudes de servicio

Estos son los pasos e hitos clave que debe registrar en el Registro de eventos para descubrir y optimizar el proceso con precisión.

5 Recomendado 8 Opcional

	Actividad	Descripción
	Solicitud asignada	Esta actividad se produce cuando se asigna una solicitud de servicio a un agente o equipo concreto para que la resuelva. Jira registra explícitamente los cambios en el campo «Assignee», lo que permite saber cuándo se realizó la asignación.
Por qué es importante Este es un hito clave para medir el tiempo entre la clasificación inicial y la asignación, así como la distribución de la carga de trabajo de los agentes. Marca el paso de la espera a la gestión activa. Dónde obtenerlo Se registra en el historial de la incidencia al buscar la primera vez que se completa el campo «Assignee» o que cambia de estar sin asignar. Capturar Utilice la fecha y hora del primer cambio del campo «Assignee» en el historial de la incidencia. Tipo de evento explicit
	Solicitud de servicio cerrada	Representa el cierre administrativo definitivo de la solicitud de servicio, que suele producirse automáticamente tras un periodo determinado en el estado «Resuelto». Es el punto final del ciclo de vida de la incidencia en Jira.
Por qué es importante Es el evento final definitivo del proceso. Analizar el tiempo entre «Resuelto» y «Cerrado» permite conocer la carga administrativa o las políticas de cierre automático. Dónde obtenerlo Se infiere del historial de la incidencia. La fecha y hora corresponden al último cambio de estado a «Cerrado» o a otro estado terminal equivalente. Capturar Identificar la fecha y hora del último cambio a un estado «Cerrado». Tipo de evento inferred
	Solicitud de servicio creada	Esta actividad marca el inicio del ciclo de vida de una solicitud de servicio, cuando una persona la presenta formalmente a través de un portal, por correo electrónico u otro canal. Jira registra este evento de forma explícita cuando se crea una incidencia nueva de tipo «Solicitud de servicio», junto con la fecha y hora de creación.
Por qué es importante Este es el evento de inicio principal del proceso. Es fundamental para calcular el tiempo de ciclo total y comprender el volumen y los patrones de llegada de las solicitudes. Dónde obtenerlo Es un evento explícito que se registra en la tabla del historial de incidencias. La fecha y hora de la actividad corresponden al campo «created» de la incidencia de Jira. Capturar Utilice la fecha y hora de creación de la incidencia de la tabla «issues» o del historial. Tipo de evento explicit
	Solicitud de servicio resuelta	Indica el momento oficial en que se considera atendida la solicitud y se registra la solución. Jira completa el campo «Fecha de resolución» cuando una incidencia pasa por primera vez a un estado de la categoría «Hecho».
Por qué es importante Es un hito final clave del proceso, fundamental para calcular el tiempo de resolución y el cumplimiento del SLA. Marca el fin del trabajo activo. Dónde obtenerlo Es un evento explícito. La fecha y hora corresponden al valor del campo «Fecha de resolución» de la incidencia de Jira, que se establece en la primera transición a un estado de la categoría «Hecho». Capturar Utilice el campo «resolutiondate» de la incidencia de Jira. Este campo se completa automáticamente. Tipo de evento explicit
	Solución propuesta	En muchos flujos de trabajo de la mesa de ayuda, este es un paso específico en el que se ofrece una solución a quien presentó la solicitud para que la apruebe. Se infiere cuando el estado de la incidencia cambia a «Pendiente de aceptación del cliente» o «A la espera de confirmación».
Por qué es importante Esta actividad permite aislar el tiempo de espera de la retroalimentación del cliente después de ofrecerle una solución y diferenciarlo del tiempo de trabajo interno. Dónde obtenerlo Se infiere del historial de la incidencia y se registra en la fecha y hora en que el estado cambia a uno que indica que la solución está pendiente de validación por parte del cliente. Capturar Identifique la fecha y hora del cambio de estado a «Pendiente de aceptación del cliente» o a un estado equivalente. Tipo de evento inferred
	Fin de la intervención del proveedor	Representa el momento en que el proveedor externo termina su intervención y la solicitud de servicio vuelve al equipo interno. Se infiere cuando la incidencia deja el estado «Esperando al proveedor».
Por qué es importante Medir la duración de la intervención del proveedor ayuda a gestionar su rendimiento y a comprender el impacto de terceros en los tiempos de resolución generales. Dónde obtenerlo Se infiere del historial de la incidencia. La fecha y hora corresponden al momento en que el estado cambia de un estado de proveedor a «En curso». Capturar Identifique cuándo cambia el campo «status» de un estado de proveedor a un estado activo. Tipo de evento inferred
	Información proporcionada	Se produce cuando quien presentó la solicitud responde con la información necesaria y el agente puede reanudar el trabajo. Se infiere cuando la incidencia deja el estado «Esperando al cliente», a menudo después de que la persona añada un comentario.
Por qué es importante Esta actividad completa el ciclo de solicitud y respuesta con el cliente. El tiempo transcurrido entre la solicitud y la recepción de la información es un componente clave del tiempo de espera del proceso. Dónde obtenerlo Se infiere del historial de la incidencia. La fecha y hora corresponden al momento en que el estado cambia de «Esperando al cliente» a «En curso». Capturar Identifique cuándo cambia el campo «status» 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 presentó la solicitud para poder resolverla. Por lo general, se infiere cuando la incidencia pasa a un estado como «Esperando al cliente» o «Pendiente de información».
Por qué es importante Los ciclos frecuentes o prolongados de «Información solicitada» pueden indicar que las solicitudes iniciales no son claras o que la comunicación es ineficiente, y constituyen una fuente importante de demoras. Dónde obtenerlo Se infiere del historial de la incidencia. La fecha y hora corresponden al momento en que el estado cambia a «Esperando al cliente» o a un estado equivalente. Capturar Identifique cuándo cambia el campo «status» a un valor que indique que el proceso está a la espera del cliente. Tipo de evento inferred
	Inicio de la intervención del proveedor	Esta actividad indica que la solicitud de servicio se ha escalado a un proveedor externo o requiere que este, u otro tercero, actúe. Se infiere cuando la incidencia pasa a un estado como «Esperando al proveedor» o «Con un tercero».
Por qué es importante Registrar la intervención del proveedor es fundamental para identificar dependencias externas y demoras que escapan al control directo de la mesa de ayuda interna. Dónde obtenerlo Se infiere del historial de la incidencia. La fecha y hora corresponden al momento en que el estado cambia a un estado designado para proveedores. Capturar Identifique cuándo cambia el campo «status» a un valor como «Esperando al proveedor». Tipo de evento inferred
	Resolución confirmada	Se produce cuando quien presentó la solicitud acepta formalmente la solución propuesta, lo que suele activar un cambio automático al estado «Resuelta». Por lo general, este evento se infiere a partir de ese cambio de estado.
Por qué es importante Este hito confirma la eficacia de la solución y activa la detención del reloj del SLA. También permite medir cuánto tardan los clientes en confirmar que el problema se ha resuelto. Dónde obtenerlo Se infiere del historial de la incidencia. La fecha y hora corresponden al cambio de estado de «Pendiente de aceptación del cliente» a «Resuelta» o «Cerrada». Capturar Identificar la fecha y hora del cambio de estado de «Pendiente de aceptación del cliente» a «Resuelto» o «Cerrado». Tipo de evento inferred
	Solicitud clasificada	Representa la evaluación inicial de una solicitud de servicio, en la que se determinan su prioridad, categoría e impacto. Por lo general, esta actividad se infiere a partir de un cambio de estado, como pasar de «Nueva» a «En curso», o de un estado específico de «Clasificada».
Por qué es importante Analizar el tiempo de clasificación permite evaluar la eficiencia de la gestión inicial de las solicitudes. Las demoras en esta etapa pueden afectar considerablemente los tiempos de resolución y el cumplimiento de los SLA. Dónde obtenerlo Se infiere del historial de la incidencia al identificar la primera fecha y hora en que el estado cambia de «Nueva» o «Abierta» a un estado activo, como «En curso». Capturar Identifique el primer cambio de estado desde «Nueva» o desde un estado inicial equivalente, según el flujo de trabajo del proyecto. Tipo de evento inferred
	Solicitud reabierta	Esta actividad registra los casos en que una solicitud de servicio ya resuelta vuelve a un estado activo. Se infiere cuando el estado cambia de resuelto o cerrado a abierto o en curso.
Por qué es importante Registrar las solicitudes reabiertas es fundamental para medir la calidad de las resoluciones y la tasa de resolución en el primer contacto. Una tasa elevada de reapertura indica que las soluciones no son eficaces o que los problemas se repiten. Dónde obtenerlo Se infiere del historial de la incidencia al identificar un cambio de estado de una categoría «Resuelta» o «Cerrada» a una categoría «Abierta» o «En curso». Capturar Busque un cambio de estado de una categoría «Hecho» a una categoría «Por hacer» o «En curso». Tipo de evento inferred
	Solución implementada	Indica que el agente ha realizado las acciones necesarias o ha desarrollado una solución para atender la solicitud de servicio. A menudo se infiere a partir de un cambio de estado a «Pendiente de revisión» o directamente a «Resuelta».
Por qué es importante Este hito marca la finalización del trabajo principal de resolución. El tiempo hasta esta actividad suele corresponder a la parte del proceso que aporta más valor. Dónde obtenerlo Se infiere del historial de la incidencia y corresponde a la fecha y hora del cambio de estado a «Resuelta», «Pendiente de aceptación» o un estado similar previo al cierre. Capturar Identifique cuándo cambia el campo «status» a un valor que indique 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) indicada en la sección de consultas para filtrar las solicitudes de servicio 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 obtenidas y confirme que corresponde al conjunto de datos correcto.
En la esquina superior derecha de la página de resultados de búsqueda, haga clic en el icono Exportar (suele tener forma de cuadro con una flecha hacia fuera).
En el menú desplegable, seleccione XML. Es fundamental usar XML, ya que la exportación CSV estándar no incluye el historial detallado de cambios necesario para generar un Registro de eventos completo.
Guarde el archivo XML descargado en su sistema local. Contiene todas las incidencias de la consulta, con el historial completo de cambios incluido en los datos de cada una.
Como el XML exportado no tiene el formato de un Registro de eventos, es necesario procesarlo posteriormente. 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 «estado» y «persona asignada» que correspondan a las actividades requeridas. Debe generar una fila nueva por 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 requeridos y recomendados.
El resultado final del script será el Registro de eventos. Guarde el 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 filtrar por un período específico para controlar el tamaño de la exportación. Utilice una cláusula como created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Un período de entre 3 y 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 «Examinar proyectos» para el proyecto de Jira especificado, a fin de ver y exportar las incidencias.
Volumen de datos: La exportación predeterminada de la interfaz de Jira suele estar limitada a 1.000 incidencias por vez. Si la consulta devuelve más resultados, deberá exportar los datos en lotes más pequeños, acotando el intervalo de fechas de cada exportación.

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: Solicite credenciales de solo lectura y los datos de conexión (nombre de host, puerto y nombre de la base de datos) de la base de datos SQL de la instancia de Jira. Por lo general, necesitará la ayuda de un administrador de bases de datos o del departamento de TI.
Identifique el esquema de Jira: Conéctese a la base de datos con un cliente SQL como DBeaver, SQuirreL SQL o SQL Server Management Studio. Familiarícese con las tablas principales: jiraissue (datos básicos de las incidencias), changegroup (historial de cambios), changeitem (detalles de cada cambio), project (detalles de los proyectos), issuetype y priority.
Localice los ID de los campos personalizados: Atributos como RequestType y SlaDueDate suelen ser campos personalizados. Identifique sus ID consultando la tabla customfield: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Anote estos ID para utilizarlos en la consulta principal.
Personalice la consulta SQL: Copie el script SQL proporcionado en su cliente SQL. Sustituya cuidadosamente todos los marcadores de posición entre corchetes por los valores reales de su configuración de Jira. Esto incluye las claves de proyecto, los nombres de tipos de incidencia y estados, y los ID de los 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 período de extracción de datos.
Ejecute la consulta: Ejecute el script SQL modificado. La consulta está diseñada para 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, compruebe brevemente que haya filas y que las columnas ServiceRequestId, ActivityName y EventTime tengan los valores esperados.
Exporte los datos: Exporte el conjunto completo de resultados desde su cliente SQL a un archivo CSV. Asígnele un nombre descriptivo, como jira_servicerequest_eventlog.csv.
Prepare los datos para cargarlos: Abra el archivo CSV y compruebe que los encabezados de columna coincidan exactamente con los nombres de atributos requeridos, por ejemplo, ServiceRequestId, ActivityName y EventTime. Asegúrese de guardar el archivo con codificación UTF-8 para que sea compatible con ProcessMind.

Configuración

Requisitos previos: Se requiere acceso directo de solo lectura a la base de datos de producción o a una 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 de Service Desk, incluidos los nombres exactos de los estados, los tipos de incidencia y los 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]'): 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, no incidentes, problemas ni 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 período 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 se asignen correctamente en la consulta. Sustituya marcadores como [Status for Triage], [Waiting for Customer Status] y [Resolved Status] por los nombres que se utilizan en su Workflow.
Consideraciones de rendimiento: Ejecutar esta consulta directamente en una base de datos de Jira grande y activa puede consumir muchos recursos y afectar el rendimiento de la aplicación para sus usuarios. Se recomienda realizar la extracción desde una base de datos réplica de solo lectura o fuera de las horas de mayor actividad.

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 instalada la versión 3.6 o posterior de Python en su sistema. Instale las bibliotecas necesarias de Python ejecutando este comando en la 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 «Configuración de la cuenta» y, a continuación, abra la pestaña «Seguridad» para crear un token de API. Guárdelo de forma segura, ya que se utilizará para la autenticación.
Identifique los ID de los campos personalizados: Muchos atributos de Jira, como «Tipo de solicitud» o «Fecha límite del SLA», son campos personalizados. Para encontrar sus ID, vaya a «Configuración» > «Incidencias» > «Campos personalizados». Busque el campo que necesita y haga clic en los tres puntos «...» > «Ver información del campo». El ID aparece en la URL, por ejemplo, customFieldId=10021. Anote estos ID 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 al inicio 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. Actualice esta asignación para que coincida con el Workflow de Jira Service Management de su organización. Las claves deben ser los nombres exactos de los estados de Jira, por ejemplo, «Waiting for customer», y los valores, los nombres de actividad correspondientes que requiere el Registro de eventos, por ejemplo, «Información solicitada».
Ejecute el script de extracción: Abra una terminal o una ventana de comandos, 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: Al terminar, el script generará un archivo CSV llamado jira_event_log.csv en el mismo directorio. Ábralo en una aplicación de hojas de cálculo y compruebe su contenido. Verifique que todas las columnas estén presentes y tengan los valores esperados.
Prepare los datos para cargarlos en ProcessMind: Asegúrese de que los encabezados de columna del archivo CSV coincidan exactamente con los requisitos: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType y SlaDueDate. El archivo ya está listo para cargarse 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 específico 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. Personalice esta asignación para reflejar el Workflow específico de Jira de su organización. Se ignorarán los estados que no estén incluidos en el mapa.
ID de campos personalizados (CUSTOM_FIELD_IDS): Para extraer datos de campos personalizados como «Tipo de solicitud» o «Fecha límite del SLA», debe proporcionar sus ID únicos del sistema, por ejemplo, customfield_10021. Deben configurarse correctamente para que se completen los atributos.
Intervalo de fechas y rendimiento: Para las extracciones iniciales, se recomienda utilizar un intervalo de fechas JQL de 3 a 6 meses para mantener un rendimiento adecuado. Extraer datos de varios años puede ser lento debido a la paginación de la API y a los límites de solicitudes.

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

¿Todo listo para empezar?

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

Volver a la guía de mejora

Descargar Template

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

Logre un 70 % de automatización y elimine las demoras en la atención. Mejore la eficiencia ahora.

Comience su prueba gratuita

No se requiere tarjeta de crédito. La configuración toma solo 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 gestión de solicitudes de servicio

Guías de extracción

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

Pasos

Configuración

Consulta de ejemplo config

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

Pasos

Configuración

Consulta de ejemplo sql

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

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para empezar?

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