Su Template de datos para la gestión de cambios

Este atributo registra el nombre de la actividad que tuvo lugar en un momento concreto de una solicitud de cambio. Estas actividades se derivan de las transiciones de estado, los pasos del flujo de trabajo o las entradas específicas del registro de Jira, como «Cambio enviado para revisión» o «Implementación iniciada».

Analizar la secuencia y la frecuencia de estas actividades es la base de Process Mining. Permite descubrir los flujos reales del proceso, identificar cuellos de botella entre etapas y analizar las variantes del proceso en comparación con el procedimiento operativo estándar.

Define las etapas del proceso, algo fundamental para descubrir mapas de procesos, analizar variantes e identificar cuellos de botella.

Por lo general, se obtiene del historial de la incidencia de Jira, en particular 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 de 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 los tiempos de ciclo, la duración entre actividades y los tiempos de espera, así como para determinar la secuencia de los eventos. Es 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 del historial de la incidencia 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. Sirve como identificador del caso en Process Mining y vincula todos los eventos, cambios de estado y actualizaciones para ofrecer una visión integral del proceso.

Durante el análisis, este ID permite reconstruir el ciclo de vida completo de cada cambio. Es fundamental para hacer un seguimiento de los cambios en las distintas 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 utilizan este atributo para agrupar y relacionar correctamente los datos de eventos de cada cambio.

Es el identificador fundamental del caso, que permite seguir todo el recorrido de una solicitud de cambio y analizar su rendimiento.

Es la clave estándar de la incidencia de Jira, que se encuentra en el campo key de las incidencias del tipo «Change request».

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

En un contexto empresarial más amplio, donde se pueden combinar datos de varios sistemas, este campo es fundamental para conocer el origen de los datos, resolver problemas y comprender las variaciones del proceso propias de cada sistema. Permite saber con claridad de dónde proceden los datos analizados.

Proporciona información clara sobre el origen de los datos, algo fundamental al combinar datos de varios sistemas o realizar auditorías.

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

Este atributo registra la fecha y hora en que se extrajeron por última vez los datos del sistema de origen. Indica qué tan actualizados están los datos en la herramienta de Process Mining.

Analizar este atributo ayuda a saber cuán recientes son los datos del proceso, algo importante para los Dashboards operativos y la supervisión en tiempo real. Aporta contexto al análisis y evita tomar decisiones basadas en datos desactualizados.

Indica qué tan actualizados están los datos y permite que los análisis sean pertinentes y se basen en información reciente.

Es un campo de metadatos que la herramienta de extracción de datos completa al extraerlos.

El campo «Asignado a» identifica al usuario responsable del paso o la actividad actual del flujo de trabajo de gestión de cambios. La persona asignada puede cambiar varias veces durante el ciclo de vida de una solicitud, a medida que esta pasa por distintas personas y equipos.

Este atributo se utiliza para analizar la distribución de la carga de trabajo, identificar cuellos de botella asociados a usuarios concretos y comprender la asignación de recursos. El Dashboard «Carga de trabajo por actividad del equipo de cambios» 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 en personas o equipos.

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

Este atributo indica el estado de la solicitud de cambio, por ejemplo, «Pendiente de aprobación», «En curso» o «Cerrada». El campo de estado de Jira es fundamental para su motor de flujo de trabajo, y los cambios en este campo determinan en gran medida el flujo del proceso.

Analizar el estado permite hacer un seguimiento del avance de los cambios activos y conocer el resultado de los ya completados, por ejemplo, «Cerrada: correcta» frente a «Cerrada: fallida». Es clave para crear Dashboards de rendimiento y analizar los ciclos de retrabajo en los que el estado vuelve a una etapa anterior.

Ofrece una visión clara del avance y el resultado final de una solicitud de cambio, algo fundamental 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 flujo de trabajo del proyecto.

Este atributo calculado compara la fecha real de resolución de una solicitud de cambio con su «Fecha prevista de finalización». El resultado es un estado sencillo, como «Cumplido» o «Incumplido».

Ofrece una indicación clara e inmediata del rendimiento en el Dashboard «Monitor del rendimiento del SLA de cambios». También simplifica la creación de KPI como «Tasa de cumplimiento del SLA de cambios», ya que calcula previamente el estado de cada caso. Así, es fácil filtrar y agregar los datos para ver qué tipos de cambio, equipos o servicios suelen incumplir el SLA.

Ofrece un resultado claro, de dos opciones, sobre el cumplimiento del SLA en cada caso, lo que simplifica los informes y el análisis.

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

Este atributo almacena la fecha en que debe completarse la solicitud de cambio para cumplir el SLA. Es el valor de referencia con el que se compara el tiempo real de finalización.

Esta fecha es fundamental para supervisar el cumplimiento de los compromisos. Sirve de base para el Dashboard «Monitor del rendimiento del SLA de cambios» y el KPI «Tasa de cumplimiento del SLA de cambios». Al comparar la fecha real de resolución con la prevista, las organizaciones pueden medir la eficacia de la prestación de sus servicios.

Es el dato principal para calcular el cumplimiento del SLA e identificar los cambios que corren el riesgo de superar la fecha 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 suele influir en el flujo de trabajo de aprobación requerido.

En Process Mining, este atributo es fundamental para el análisis basado en riesgos. Permite al Dashboard «Precisión y resultados de la evaluación de riesgos» relacionar el riesgo inicial con el resultado real. También es la dimensión principal del KPI «Tasa de cambios fallidos por nivel de riesgo», que ayuda a evaluar si los cambios de alto riesgo se gestionan de forma eficaz.

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

Suele ser un campo personalizado de Jira Service Management. Algunos nombres habituales son «Nivel de riesgo» e «Impacto».

El campo «Prioridad» 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.

Analizar la prioridad permite comparar el rendimiento de los cambios de prioridad alta y baja. Por ejemplo, se puede comprobar si los cambios de alta prioridad realmente tienen tiempos de ciclo más cortos o si se atascan en los mismos cuellos de botella que los demás. Esto resulta útil para optimizar la asignación de recursos y cumplir las expectativas del negocio.

Permite analizar el rendimiento del proceso según la prioridad para el negocio y comprobar si los cambios críticos se agilizan como se espera.

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

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

Este atributo es esencial para el análisis de procesos, ya que los distintos tipos de cambio suelen seguir rutas diferentes y tener distintos SLA. Se utiliza para calcular el KPI «Tasa de cambios de emergencia» y filtrar los Dashboards para comparar el rendimiento y el riesgo de cada tipo.

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

Suele ser un campo personalizado en los proyectos de Jira Service Management. El nombre puede variar, aunque a menudo se denomina «Tipo de cambio».

Este atributo identifica al equipo asignado para trabajar en el cambio. Jira cuenta con el campo «Asignado a» para las personas, pero el campo «Equipo» suele utilizarse para asignar el trabajo a un grupo funcional, como «Operaciones de red» o «Administración de bases de datos».

Este atributo es fundamental para el Dashboard «Carga de trabajo por actividad del equipo de cambios». Permite analizar el rendimiento y los cuellos de botella a nivel de equipo, en lugar de limitarse a cada persona, lo que suele ser más útil para planificar y gestionar los recursos.

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

Suele ser un campo personalizado de Jira, ya que no existe un campo estándar «Equipo». Puede ser de tipo «Selector de grupos» o una lista de selección sencilla.

Este atributo calculado identifica las solicitudes de cambio que han vuelto a una etapa anterior para realizar modificaciones, por ejemplo, de «Pendiente de aprobación» a «Planificación». Indica que la solicitud inicial estaba incompleta, era incorrecta o no cumplía los criterios necesarios.

Este indicador sirve de base para el KPI «Tasa de retrabajo de cambios» y el Dashboard «Análisis de retrabajo y rechazo de cambios». Al marcar los casos con retrabajo, los analistas pueden filtrarlos fácilmente e investigar las causas, como una planificación inicial deficiente, requisitos poco claros o una evaluación de riesgos insuficiente.

Pone de manifiesto las ineficiencias del proceso al marcar los casos que requirieron trabajo adicional no previsto, lo que permite analizar las causas del retrabajo.

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

Este atributo indica si el cambio tuvo un resultado negativo, como un incidente en producción. Para ello, normalmente se vincula la incidencia de solicitud de cambio con una o varias incidencias en Jira.

Estos datos son esenciales para calcular los KPI «Tasa de incidencias posteriores a la implementación» y «Tasa de cambios fallidos». Ofrecen 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 mejorar los controles y prevenir fallos futuros.

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

Suele calcularse comprobando si hay incidencias vinculadas en Jira, en concreto, si una incidencia de cambio tiene vínculos «es causada por» con incidencias de tipo incidente.

El informador es la persona que creó la incidencia de solicitud de cambio en Jira. A menudo es quien está a cargo del cambio o quien lo inicia en nombre de un equipo.

Analizar quién informa permite identificar qué departamentos, equipos o personas inician más cambios. También ayuda a detectar tendencias en el origen de los cambios y a ofrecer retroalimentación o formación a los grupos que suelen presentar solicitudes incompletas o de baja calidad.

Ayuda a identificar el origen de las solicitudes de cambio y permite analizarlo para mejorar la calidad de las solicitudes iniciales.

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

Este atributo recoge el motivo de fondo del cambio, como «Implementación de una nueva funcionalidad», «Corrección de errores» o «Actualización de infraestructura». Aporta un contexto importante que va más allá del resumen o la descripción.

En el análisis, el motivo del 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 para corregir errores que los destinados a implementar nuevas funcionalidades?» o «¿Las actualizaciones de infraestructura tienen una tasa de fallos más alta?».

Aporta contexto de negocio y permite profundizar en el análisis al relacionar el propósito de un cambio con su rendimiento y resultado.

Suele ser 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 «Resolución» aporta información concreta sobre el resultado. Por ejemplo, «Completada» indica que se realizó correctamente, mientras que «No se realizará» o «Duplicada» indican otros motivos de cierre. Así, ofrece más contexto que el estado «Cerrada» por sí solo.

Este atributo es esencial para analizar las tasas de éxito y de fallos de los cambios. Por ejemplo, el KPI «Tasa de incidencias posteriores a la implementación» se entiende mejor si se filtran los cambios con una resolución «Fallida» o «Revertida». También permite distinguir los cambios implementados correctamente de los cancelados o rechazados después de su aprobación.

Aporta información detallada sobre el resultado final de un cambio, fundamental para calcular con precisión las tasas de éxito y de fallos.

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

Este atributo vincula la solicitud de cambio con un servicio de negocio concreto definido en la base de datos de gestión de la configuración (CMDB), como «Servicio de correo electrónico» o «CRM de clientes». Es un concepto clave para comprender el impacto del cambio en el negocio.

Analizar los cambios por servicio de negocio ayuda a priorizar las iniciativas y comunicar su impacto a las partes interesadas. Permite ver qué servicios experimentan más cambios, cuáles corren más riesgos y dónde se concentran los incidentes relacionados con los cambios. Esto es fundamental para gestionar los cambios técnicos desde una perspectiva de negocio.

Relaciona los cambios técnicos con su impacto en el negocio y permite priorizar y analizar los riesgos según la importancia del servicio afectado.

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