Su Template de datos de gestión de cambios

Este atributo registra el nombre de la actividad que tuvo lugar en un momento concreto para una solicitud de cambio. Estas actividades se derivan de transiciones de estado, pasos del Workflow o entradas específicas del registro en Jira, como 'Change Submitted For Review' o 'Implementation Started'.

Analizar la secuencia y la frecuencia de estas actividades es la base del Process Mining. Permite descubrir los flujos reales del proceso, identificar cuellos de botella entre pasos y analizar las variantes del proceso respecto al procedimiento operativo estándar.

Define los pasos del proceso, algo esencial para descubrir mapas de procesos, analizar variantes e identificar cuellos de botella.

Normalmente se deriva del historial de la incidencia de Jira, concretamente de las transiciones de estado o las actualizaciones de campos personalizados que representan hitos del proceso.

La hora de inicio, o marca de tiempo del evento, indica la fecha y hora exactas en que se registró una actividad para una solicitud de cambio. Cada actividad del registro de eventos, desde la creación hasta el cierre, tiene una marca de tiempo asociada.

Este atributo es fundamental para todos los análisis temporales de Process Mining. Se utiliza para calcular tiempos de ciclo, duraciones entre actividades y tiempos de espera, así como para determinar la secuencia de eventos. Constituye la base de la supervisión del rendimiento, los cálculos de cumplimiento de los SLA y la identificación de cuellos de botella.

Esta marca de tiempo es la base de todos los análisis de rendimiento y duración, ya que permite calcular los tiempos de ciclo e identificar retrasos.

La marca de tiempo de cada entrada en el registro del historial de incidencias de Jira. Para el evento de creación, corresponde al campo created.

El ID de la solicitud de cambio es la clave principal que identifica de forma única cada iniciativa de cambio en Jira Service Management. Actúa como identificador del caso para Process Mining y vincula todos los eventos, cambios de estado y actualizaciones en una visión coherente del proceso de principio a fin.

En el análisis, este ID permite reconstruir el ciclo de vida completo de cada cambio. Es esencial para realizar el seguimiento de los cambios individuales a través de etapas como la evaluación de riesgos, la aprobación, la implementación y la revisión. Todas las métricas, los KPI y los Dashboards dependen de este atributo para agregar y correlacionar correctamente los datos de eventos de un cambio concreto.

Este es el identificador fundamental del caso, que permite rastrear todo el recorrido de una solicitud de cambio y analizar su rendimiento.

Esta es la clave estándar de incidencia de Jira, que se encuentra en el campo key de las incidencias de tipo Change request.

Este atributo especifica el sistema de origen del que proceden los datos del proceso. En este contexto, el valor es siempre «Jira Service Management».

En un contexto empresarial más amplio, en el que los datos pueden combinarse desde varios sistemas, este campo es fundamental para conocer el linaje de los datos, resolver problemas y comprender las variaciones del proceso específicas de cada sistema. Garantiza la claridad sobre el origen de los datos analizados.

Proporciona una trazabilidad clara de los datos, algo esencial al combinar datos de varios sistemas o para fines de auditoría.

Es un valor estático que se añade durante la extracción de datos para identificar el origen del conjunto de datos.

Este atributo registra la fecha y hora en que se extrajeron los datos por última vez del sistema de origen. Representa la actualidad de los datos dentro de la herramienta de Process Mining.

Analizar este atributo ayuda a comprender hasta qué punto están actualizados los datos del proceso, algo importante para los Dashboards operativos y la supervisión en tiempo real. Proporciona contexto para el análisis y garantiza que las decisiones no se tomen a partir de datos obsoletos.

Indica la actualidad de los datos y garantiza que los análisis sean pertinentes y se basen en información actualizada.

Es un campo de metadatos que la herramienta de extracción de datos completa en el momento de obtener los datos.

Este atributo indica el estado de la solicitud de cambio, por ejemplo, 'En espera de aprobación', 'En curso' o 'Cerrado'. El campo de estado de Jira es fundamental para su motor de flujo de trabajo, y los cambios en este campo impulsan principalmente el flujo del proceso.

Analizar el estado permite realizar el seguimiento del progreso de los cambios activos y comprender los resultados de los cambios completados, por ejemplo, 'Cerrado - Correcto' frente a 'Cerrado - Fallido'. Es clave para crear Dashboards de rendimiento y analizar ciclos de retrabajo en los que un estado vuelve a una fase anterior.

Ofrece una visión clara del progreso y el resultado final de una solicitud de cambio, algo crucial para analizar el rendimiento y el retrabajo.

Es el campo estándar status de una incidencia de Jira. Los estados disponibles se definen en la configuración del Workflow del proyecto.

Este atributo calculado compara la fecha real de resolución de una solicitud de cambio con su «Target Completion Date». El resultado es un estado sencillo, como «Met» o «Breached».

Proporciona un indicador claro y visible del rendimiento para el panel «Change SLA Performance Monitor». Simplifica la creación de KPI como «Change SLA Adherence Rate» al calcular previamente el estado de cada caso. Esto permite filtrar y agregar datos fácilmente para identificar qué tipos de cambio, equipos o servicios se asocian con más frecuencia a incumplimientos del SLA.

Proporciona un resultado binario claro sobre el rendimiento del SLA en cada caso y simplifica los informes y el análisis del cumplimiento del SLA.

Se calcula comparando la marca de tiempo de la actividad final «Change Closed» con el atributo «TargetCompletionDate».

Este atributo almacena la fecha en la que se espera completar la solicitud de cambio para cumplir su SLA. Es el punto de referencia con el que se compara el tiempo real de finalización.

Esta fecha es fundamental para supervisar el rendimiento frente a los compromisos. Constituye la base del panel «Change SLA Performance Monitor» y del KPI «Change SLA Adherence Rate». Al comparar la fecha real de resolución con este objetivo, las organizaciones pueden medir la eficacia de la prestación del servicio.

Es el dato principal para calcular el cumplimiento del SLA e identificar qué cambios corren el riesgo de superar sus fechas límite.

A menudo corresponde al campo duedate de Jira o a un valor de una métrica de SLA configurada en Jira Service Management.

El nivel de riesgo es una evaluación obligatoria en la mayoría de los procesos de gestión de cambios y clasifica el posible impacto negativo de un cambio. Se determina durante la fase de evaluación de riesgos y a menudo influye en el Workflow de aprobación requerido.

En Process Mining, este atributo es fundamental para el análisis basado en riesgos. Permite al panel «Risk Assessment Accuracy & Outcome» relacionar el riesgo inicial con el resultado real. También es la dimensión principal del KPI «Change Failure Rate by Risk Level», que ayuda a evaluar si los cambios de alto riesgo se gestionan de forma eficaz.

Permite analizar si los controles del proceso y los Workflows de aprobación son eficaces para distintos perfiles de riesgo, y ayuda a relacionar el riesgo con las tasas de fallo de los cambios.

Normalmente es un campo personalizado de Jira Service Management. Algunos nombres habituales son «Risk Level» e «Impact».

El campo Priority ayuda a los equipos a determinar el orden en que deben atender las solicitudes de cambio. Refleja una combinación de impacto y urgencia, y orienta la planificación y la asignación de recursos.

El análisis de la prioridad permite comparar el rendimiento de los cambios de prioridad alta y baja. Por ejemplo, puede comprobarse si los cambios de alta prioridad tienen realmente tiempos de ciclo más cortos o si se quedan atascados en los mismos cuellos de botella que otros cambios. Esto resulta útil para optimizar la dedicación de recursos y cumplir las expectativas del negocio.

Permite analizar el rendimiento del proceso según la prioridad empresarial y garantiza que los cambios críticos se aceleren como se espera.

Es el campo estándar priority de una incidencia de Jira.

El responsable es el usuario encargado del paso o la actividad actual del Workflow de gestión de cambios. Puede cambiar varias veces durante el ciclo de vida de una solicitud de cambio, a medida que esta pasa entre distintas personas y equipos.

Este atributo se utiliza para analizar la distribución de la carga de trabajo, identificar cuellos de botella específicos de cada usuario y comprender la asignación de recursos. El panel «Change Team Activity Workload» utiliza estos datos para mostrar qué personas o grupos gestionan más actividades.

Ayuda a analizar el rendimiento de los recursos y la distribución de la carga de trabajo, e identifica cuellos de botella individuales o de equipo.

Es el campo estándar assignee de una incidencia de Jira.

El tipo de cambio clasifica la solicitud de cambio según su naturaleza, urgencia e impacto. Entre los tipos habituales se incluyen 'Estándar' para cambios de bajo riesgo aprobados previamente, 'Normal' para cambios rutinarios que requieren una aprobación completa y 'Emergencia' para cambios urgentes destinados a resolver incidentes.

Este atributo es esencial para el análisis del proceso, ya que los distintos tipos de cambio suelen seguir rutas diferentes y tener SLA distintos. Se utiliza para calcular el KPI de tasa de cambios de emergencia y para filtrar Dashboards con el fin de comparar el rendimiento y el riesgo asociados a cada tipo.

Permite segmentar el proceso para analizar distintos Workflows, como los cambios estándar y de emergencia, que tienen expectativas de rendimiento y riesgos diferentes.

Normalmente es un campo personalizado en los proyectos de Jira Service Management. El nombre del campo puede variar, aunque a menudo se denomina «Change Type».

Este atributo identifica al equipo asignado para trabajar en el cambio. Aunque Jira dispone del campo «Assignee» para las personas, el campo «Team» se utiliza a menudo para asignar el trabajo a un grupo funcional, como «Network Operations» o «Database Administrators».

Es fundamental para el panel «Change Team Activity Workload». Permite analizar el rendimiento y los cuellos de botella a nivel de equipo, no solo individual, lo que suele resultar más útil para planificar y gestionar los recursos.

Facilita el análisis de la carga de trabajo y el rendimiento a nivel de equipo o departamento, y pone de relieve los cuellos de botella sistémicos.

Normalmente es un campo personalizado de Jira, ya que no existe un campo estándar «Team». Puede ser de tipo «Group Picker» o una lista de selección sencilla.

Este atributo calculado identifica las solicitudes de cambio que han vuelto a una fase anterior para realizar modificaciones, por ejemplo, cuando pasan de «Awaiting Approval» a «Planning». Indica que el envío inicial estaba incompleto, era incorrecto o no cumplía los criterios necesarios.

Este indicador constituye la base del KPI «Change Rework Rate» y del panel «Change Rework and Rejection Analysis». Al marcar los casos con retrabajo, los analistas pueden filtrarlos fácilmente e investigar sus causas raíz, como una planificación inicial deficiente, requisitos poco claros o una evaluación de riesgos insuficiente.

Pone de relieve la ineficiencia del proceso al marcar explícitamente los casos que requirieron trabajo adicional no planificado, lo que permite analizar las causas raíz del retrabajo.

Se calcula analizando la secuencia de actividades del registro de eventos. Se detecta retrabajo cuando una actividad de una fase posterior va seguida de una actividad de una fase anterior.

Este atributo indica si el cambio produjo un resultado negativo, como una incidencia en producción. A menudo implica vincular la incidencia de solicitud de cambio con una o varias incidencias en Jira.

Estos datos son esenciales para calcular los KPI «Post-Implementation Issue Rate» y «Change Failure Rate». Proporcionan una medida directa de la calidad del cambio y de la eficacia de los procesos de planificación, pruebas y evaluación de riesgos. Analizar qué cambios provocan incidencias ayuda a perfeccionar los controles y prevenir futuros fallos.

Mide directamente la calidad y el éxito de un cambio al registrar si provocó problemas operativos posteriores.

Normalmente se obtiene comprobando las incidencias vinculadas en Jira, concretamente si una incidencia de cambio tiene vínculos «is caused by» procedentes de incidencias.

El informador es la persona que creó la incidencia de solicitud de cambio en Jira. A menudo es el propietario del cambio o alguien que lo inicia en nombre de un equipo.

El análisis del informador puede ayudar a identificar qué departamentos, equipos o personas inician más cambios. También permite detectar tendencias en el origen de los cambios y ofrecer comentarios o formación a los grupos que envían con frecuencia solicitudes incompletas o de baja calidad.

Ayuda a identificar el origen de las solicitudes de cambio, que puede analizarse para mejorar la calidad de los envíos iniciales.

Es el campo estándar reporter de una incidencia de Jira.

Este atributo recoge el motivo subyacente del cambio, como «New Feature Implementation», «Bug Fix» o «Infrastructure Upgrade». Aporta un contexto esencial más allá del resumen o la descripción.

En el análisis, el motivo de un cambio puede relacionarse con otras métricas, como el tiempo de ciclo, la tasa de fallos y el nivel de riesgo. Esto ayuda a responder preguntas como «¿Se aprueban más rápido los cambios relacionados con la corrección de errores que las implementaciones de nuevas funcionalidades?» o «¿Las actualizaciones de infraestructura tienen una tasa de fallos más alta?».

Aporta contexto empresarial y permite realizar un análisis más profundo al relacionar el propósito de un cambio con su rendimiento y resultado.

Normalmente es un campo personalizado de Jira Service Management, a menudo una lista de selección o un campo de texto.

Cuando se cierra una solicitud de cambio, el campo Resolution proporciona información específica sobre el resultado. Por ejemplo, «Done» indica que se completó correctamente, mientras que «Won't Do» o «Duplicate» indican otros motivos de cierre. Esto aporta más contexto que el estado «Closed» por sí solo.

Este atributo es esencial para analizar las tasas de éxito y fallo de los cambios. Por ejemplo, el KPI «Post-Implementation Issue Rate» puede interpretarse mejor filtrando los cambios con una resolución «Failed» o «Rolled Back». Ayuda a distinguir los cambios implementados correctamente de aquellos que se cancelaron o rechazaron después de la aprobación.

Aporta un contexto detallado sobre el resultado final de un cambio, algo crucial para calcular con precisión las tasas de éxito y fallo.

Es el campo estándar resolution de Jira, que normalmente se establece cuando una incidencia pasa a una categoría de estado «Done».

Este atributo vincula la solicitud de cambio con un servicio empresarial específico definido en la Base de Datos de Gestión de la Configuración (CMDB), como «Email Service» o «Customer CRM». Es un concepto clave para comprender el impacto empresarial de un cambio.

El análisis de los cambios por servicio empresarial ayuda a priorizar esfuerzos y comunicar el impacto a las partes interesadas. Permite saber qué servicios experimentan más cambios, cuáles presentan mayor riesgo y dónde se concentran las incidencias relacionadas con los cambios. Esto es esencial para gestionar los cambios técnicos desde una perspectiva centrada en el negocio.

Relaciona los cambios técnicos con el impacto empresarial y permite priorizar y analizar los riesgos según la criticidad del servicio afectado.

A menudo es un campo personalizado de JSM, vinculado con frecuencia a Jira Assets (antes Insight) o a otra CMDB.