Su Plantilla de Datos de Gestión de Cambios

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

Analizar la secuencia y frecuencia de estas actividades es el núcleo del Process Mining. Permite el descubrimiento de los flujos de proceso reales, la identificación de cuellos de botella entre pasos y el análisis de variantes de proceso frente al procedimiento operativo estándar.

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

Típicamente derivado del historial de incidencias de Jira, específicamente de transiciones de estado o actualizaciones de campos personalizados que representan hitos del proceso.

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

Este atributo es crítico para todo análisis basado en tiempo en Process Mining. Se utiliza para calcular tiempos de ciclo, duraciones entre actividades, tiempos de espera y para determinar la secuencia de eventos. Constituye la base para el monitoreo del rendimiento, los cálculos de cumplimiento de SLA y la identificación de cuellos de botella.

Esta marca de tiempo es la base para todo análisis de rendimiento y duración, permitiendo el cálculo de los tiempos de ciclo y la identificación de retrasos.

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

El ID de Solicitud de Cambio es la clave principal que identifica de forma única cada iniciativa de cambio dentro de Jira Service Management. Sirve como identificador de caso para Process Mining, vinculando todos los eventos, cambios de estado y actualizaciones en una vista de proceso cohesiva de extremo a extremo.

En el análisis, este ID permite la reconstrucción del ciclo de vida completo de cada cambio. Es esencial para el seguimiento de cambios individuales a través de diversas etapas como la evaluación de riesgos, aprobación, implementación y revisión. Todas las métricas, KPIs y dashboards dependen de este atributo para agregar y correlacionar correctamente los datos de eventos para un cambio específico.

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

Esta es la Clave de Incidencia estándar de Jira, que se encuentra en el campo key para incidencias del tipo de solicitud de cambio.

Este atributo especifica el sistema de origen donde se originaron los datos del proceso. Para este contexto, el valor es consistentemente 'Jira Service Management'.

En un contexto empresarial más amplio donde los datos podrían fusionarse de múltiples sistemas, este campo es crucial para la trazabilidad de los datos, la resolución de problemas y la comprensión de las variaciones de proceso específicas del sistema. Asegura la claridad sobre el origen de los datos que se analizan.

Proporciona una clara procedencia de los datos, lo cual es esencial al combinar datos de múltiples sistemas o para fines de auditoría.

Este es un valor estático añadido durante la extracción de datos para etiquetar el origen del dataset.

Este atributo registra la fecha y hora en que los datos fueron extraídos por última vez del sistema de origen. Representa la frescura de los datos dentro de la herramienta de Process Mining.

Analizar este atributo ayuda a los usuarios a comprender cuán actualizados están los datos del proceso, lo cual es importante para los dashboards operativos y el monitoreo en tiempo real. Proporciona contexto para el análisis, asegurando que las decisiones no se tomen sobre datos obsoletos.

Indica la frescura de los datos, asegurando que los análisis sean relevantes y se basen en información actualizada.

Este es un campo de metadatos poblado por la herramienta de extracción de datos en el momento de la extracción de los datos.

El Asignado es el usuario individual responsable del paso o actividad actual en el workflow de gestión de cambios. El asignado puede cambiar varias veces a lo largo del ciclo de vida de una solicitud de cambio a medida que se mueve entre diferentes personas y equipos.

Este atributo se utiliza para analizar la distribución de la carga de trabajo, identificar cuellos de botella específicos del usuario y comprender la asignación de recursos. El dashboard 'Change Team Activity Workload' se basa en estos datos para mostrar qué individuos o grupos están gestionando la mayoría de las actividades.

Esto ayuda a analizar el rendimiento de los recursos y la distribución de la carga de trabajo, identificando cuellos de botella individuales o de equipo.

Este es el campo assignee estándar en una incidencia de Jira.

Este atributo indica el estado de la solicitud de cambio, como 'Awaiting Approval', 'In Progress' o 'Closed'. El campo de estado en Jira es fundamental para su motor de workflow, y los cambios en este campo son los principales impulsores del flujo del proceso.

Analizar el estado permite rastrear el progreso de los cambios activos y comprender los resultados de los completados, por ejemplo, 'Closed - Successful' versus 'Closed - Failed'. Es clave para construir dashboards de rendimiento y analizar bucles de retrabajo donde un estado revierte a un estado anterior.

Proporciona una visión clara del progreso y el resultado final de una solicitud de cambio, lo cual es crucial para el análisis de rendimiento y retrabajo.

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

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

Esto proporciona un indicador de rendimiento claro y de un vistazo para el dashboard 'Change SLA Performance Monitor'. Simplifica la creación de KPIs como 'Change SLA Adherence Rate' al precalcular el estado para cada caso. Esto permite un filtrado y agregación fáciles para ver qué tipos de cambios, equipos o servicios se asocian con mayor frecuencia a los incumplimientos de SLA.

Proporciona un resultado claro y binario para el rendimiento de SLA en cada caso, simplificando la elaboración de informes y el análisis del cumplimiento de SLA.

Calculado comparando la marca de tiempo de la actividad final 'Cambio Cerrado' con el atributo 'TargetCompletionDate'.

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

Esta fecha es fundamental para monitorear el rendimiento frente a los compromisos. Es la base para el dashboard 'Change SLA Performance Monitor' y el KPI 'Change SLA Adherence Rate'. Al comparar la fecha de resolución real con este objetivo, las organizaciones pueden medir la efectividad de su entrega de servicio.

Este es el punto de datos principal para calcular el cumplimiento de SLA e identificar qué cambios corren el riesgo de incumplir sus plazos.

Este es a menudo el campo duedate en Jira o 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, categorizando el impacto negativo potencial de un cambio. El nivel 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 crítico para el análisis basado en riesgos. Soporta el dashboard 'Risk Assessment Accuracy & Outcome' al correlacionar el riesgo inicial con el resultado real. También es la dimensión principal para el KPI 'Change Failure Rate by Risk Level', ayudando a evaluar si los cambios de alto riesgo se gestionan eficazmente.

Permite analizar si los controles de proceso y los workflows de aprobación son efectivos para diferentes perfiles de riesgo, y ayuda a correlacionar el riesgo con las tasas de fallo de los cambios.

Este es típicamente un campo personalizado en Jira Service Management. Los nombres comunes incluyen 'Risk Level' o 'Impact'.

El campo de Prioridad ayuda a los equipos a determinar el orden en que abordar las solicitudes de cambio. Refleja una combinación de impacto y urgencia y guía la programación y asignación de recursos.

Analizar la prioridad permite comparaciones de rendimiento entre cambios de alta y baja prioridad. Por ejemplo, se puede verificar si los cambios de alta prioridad realmente tienen tiempos de ciclo más cortos o si se quedan atascados en los mismos cuellos de botella que otros cambios. Esto es valioso para optimizar el enfoque de los recursos y cumplir con las expectativas del negocio.

Permite el análisis del rendimiento del proceso basado en la prioridad del negocio, asegurando que los cambios críticos se agilicen como se espera.

Este es el campo priority estándar en una incidencia de Jira.

Esta es una métrica calculada que mide el tiempo transcurrido entre la actividad 'Change Submitted For Review' y la actividad 'Change Request Approved'. Aísla la fase de aprobación del ciclo de vida del cambio para un análisis enfocado.

Esta métrica soporta directamente el dashboard 'Change Approval Cycle Time' y el KPI correspondiente. Se utiliza para identificar cuellos de botella en el proceso de aprobación, ya sean con grupos de aprobación específicos, tipos de cambio o niveles de riesgo. Reducir este tiempo puede acelerar significativamente el proceso general de entrega de cambios.

Mide directamente la eficiencia de la etapa de aprobación, ayudando a identificar y abordar los retrasos en la autorización de los cambios.

Calculado restando la marca de tiempo de 'Cambio Enviado para Revisión' de la marca de tiempo de 'Solicitud de Cambio Aprobada' para un ID de Solicitud de Cambio dado.

El Tipo de Cambio categoriza la solicitud de cambio según su naturaleza, urgencia e impacto. Los tipos comunes incluyen 'Standard' para cambios preaprobados de bajo riesgo, 'Normal' para cambios rutinarios que requieren aprobación completa y 'Emergency' para cambios urgentes para corregir incidencias.

Este atributo es esencial para el análisis de procesos, ya que los diferentes tipos de cambio a menudo siguen distintas rutas de proceso y tienen diferentes SLA. Se utiliza para calcular el KPI de 'Emergency Change Rate' y para filtrar dashboards para comparar el rendimiento y el riesgo asociados con cada tipo.

Permite la segmentación del proceso para analizar diferentes workflows, como cambios estándar versus cambios de emergencia, que tienen expectativas de rendimiento y riesgos únicos.

Este es típicamente un campo personalizado en proyectos de Jira Service Management. El nombre del campo puede variar, pero a menudo se llama 'Change Type'.

Este atributo calculado identifica las solicitudes de cambio que han sido enviadas de vuelta a una etapa anterior para modificaciones, por ejemplo, moviéndose de 'Awaiting Approval' de vuelta a 'Planning'. Señala que la presentación inicial fue incompleta, incorrecta o no cumplió con los criterios necesarios.

Esta bandera es la base para el KPI 'Change Rework Rate' y el dashboard 'Change Rework and Rejection Analysis'. Al marcar los casos de reproceso, los analistas pueden filtrarlos fácilmente e investigar las causas raíz, como una mala planificación inicial, requisitos poco claros o una evaluación de riesgos insuficiente.

Destaca la ineficiencia del proceso al señalar explícitamente los casos que requirieron trabajo adicional y no planificado, lo que permite analizar las causas raíz del retrabajo.

Calculado analizando la secuencia de actividades en el registro de eventos. Se detecta un retrabajo si una actividad de etapa posterior es seguida por una actividad de etapa anterior.

Este atributo identifica al equipo asignado para trabajar en el cambio. Si bien Jira tiene un campo 'Assignee' para individuos, a menudo se utiliza un campo 'Team' para asignar trabajo a un grupo funcional, como 'Network Operations' o 'Database Administrators'.

Esto es crucial para el dashboard 'Change Team Activity Workload'. Permite el análisis del rendimiento y los cuellos de botella a nivel de equipo, en lugar de solo a nivel individual, lo cual suele ser más útil para la planificación y gestión de recursos.

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

Este suele ser un campo personalizado en Jira, ya que no existe un campo 'Team' estándar. Podría ser de tipo 'Group Picker' o una lista de selección simple.

Este atributo indica si el cambio resultó en un resultado negativo, como una incidencia de producción. Esto a menudo implica vincular la incidencia de solicitud de cambio a una o más incidencias en Jira.

Estos datos son esenciales para calcular los KPI de 'Post-Implementation Issue Rate' y 'Change Failure Rate'. Proporciona una medida directa de la calidad del cambio y la efectividad de los procesos de planificación, prueba y evaluación de riesgos. Analizar qué cambios conducen a incidencias ayuda a refinar los controles y prevenir fallos futuros.

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

Esto se deriva típicamente al verificar incidencias vinculadas en Jira, específicamente si una incidencia de Cambio tiene vínculos 'is caused by' de incidencias de Incidente.

Este atributo captura la razón subyacente del cambio, como 'New Feature Implementation', 'Bug Fix' o 'Infrastructure Upgrade'. Proporciona un contexto crucial más allá del resumen o la descripción.

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

Proporciona un contexto de negocio que permite un análisis más profundo al correlacionar el propósito de un cambio con su rendimiento y resultado.

Este es típicamente un campo personalizado en Jira Service Management, a menudo una lista de selección o campo de texto.

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

Analizar el reportero puede ayudar a identificar qué departamentos, equipos o individuos están iniciando la mayoría de los cambios. Se puede utilizar para detectar tendencias en las fuentes de cambio y proporcionar retroalimentación o capacitación a grupos que frecuentemente presentan solicitudes de cambio incompletas o de baja calidad.

Ayuda a identificar las fuentes de las solicitudes de cambio, que pueden analizarse para mejorar la calidad de las presentaciones iniciales.

Este es el campo reporter estándar en una incidencia de Jira.

Cuando se cierra una solicitud de cambio, el campo Resolución proporciona información específica sobre el resultado. Por ejemplo, 'Done' indica éxito, mientras que 'Won't Do' o 'Duplicate' proporcionan otras razones de cierre. Esto ofrece más contexto que el estado 'Closed' por sí solo.

Este atributo es esencial para analizar las tasas de éxito y fracaso del cambio. Por ejemplo, el KPI 'Post-Implementation Issue Rate' se puede entender mejor filtrando los cambios con una resolución 'Failed' o 'Rolled Back'. Ayuda a distinguir los cambios implementados con éxito de aquellos que fueron cancelados o rechazados después de la aprobación.

Proporciona contexto detallado sobre el resultado final de un cambio, lo cual es crucial para calcular con precisión las tasas de éxito y fracaso.

Este es el campo resolution estándar en Jira, que se establece típicamente cuando una incidencia se mueve a una categoría de estado 'Done'.

Este atributo vincula la solicitud de cambio a un servicio de negocio específico definido en la Base de Datos de Gestión de Configuración (CMDB), como 'Email Service' o 'Customer CRM'. Este es un concepto clave para entender el impacto de negocio de un cambio.

Analizar los cambios por servicio de negocio ayuda a priorizar esfuerzos y comunicar el impacto a los stakeholders. Permite una vista de qué servicios están experimentando la mayor cantidad de cambios, cuáles están en mayor riesgo y dónde se concentran las incidencias relacionadas con los cambios. Esto es vital para gestionar los cambios técnicos desde una perspectiva centrada en el negocio.

Conecta los cambios técnicos con el impacto empresarial, permitiendo la priorización y el análisis de riesgos basado en la criticidad del servicio afectado.

Este es a menudo un campo personalizado en JSM, frecuentemente vinculado a Jira Assets (anteriormente Insight) u otra CMDB.