Su Template de datos de Change Management

Ivanti Cherwell
Su Template de datos de Change Management

Su Template de datos de Change Management

Esta plantilla ofrece una hoja de ruta clara para recopilar los datos esenciales necesarios para analizar su proceso de Change Management. Detalla los atributos clave que debe recopilar, las actividades principales que debe seguir y proporciona instrucciones específicas para extraer esta información de su sistema de origen. Utilice este recurso para crear un Registro de eventos sólido para sus iniciativas de Process Mining.
  • Atributos recomendados para recopilar
  • Actividades clave que debe seguir
  • Guía de extracción desde Ivanti Cherwell
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos de la gestión de cambios

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para realizar un análisis completo de la gestión de cambios y obtener información útil para descubrir el proceso.
5 Obligatorio 6 Recomendado 8 Opcional
Nombre Descripción
Hora del evento
EventTime
La marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específicos de la solicitud de cambio.
Descripción

La hora del evento, también conocida como marca de tiempo, registra la fecha y hora exactas en que tuvo lugar una actividad. Estos datos temporales son esenciales para ordenar cronológicamente los eventos y constituyen la base de todo análisis de Process Mining basado en el tiempo.

Este atributo se utiliza para calcular las duraciones entre actividades, medir el tiempo de ciclo total de los casos e identificar tiempos de espera o retrasos en el proceso. Es fundamental para crear Dashboards que supervisen el rendimiento frente a objetivos basados en el tiempo, como «Change Approval Cycle Time».

Por qué es importante

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, identificar cuellos de botella y supervisar los SLA.

Dónde obtenerlo

Normalmente se encuentra en registros de cambios de estado, pistas de auditoría o marcas de tiempo de entradas de diario asociadas al objeto Change Request en Ivanti Cherwell.

Ejemplos
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
ID de la solicitud de cambio
ChangeRequestId
El identificador único de un caso de solicitud de cambio, que agrupa todas las actividades relacionadas desde el inicio hasta el cierre.
Descripción

El ID de la solicitud de cambio es la clave principal que identifica de forma única cada iniciativa de cambio durante todo su ciclo de vida. Actúa como identificador del caso en Process Mining y vincula todos los eventos, como el envío, la evaluación, la aprobación y la implementación, en una única instancia de proceso coherente.

El análisis de los datos mediante el ID de la solicitud de cambio ofrece una visión completa, de extremo a extremo, del proceso de gestión de cambios. Esto permite realizar el seguimiento de cada cambio, calcular los tiempos totales del ciclo e identificar desviaciones del proceso o cuellos de botella específicos de cada solicitud.

Por qué es importante

Este es el identificador esencial del caso que conecta todos los eventos relacionados, lo que permite seguir todo el recorrido de una solicitud de cambio y analizar su rendimiento.

Dónde obtenerlo

Normalmente es el identificador principal del objeto de negocio Change Request en Ivanti Cherwell.

Ejemplos
CR-105421CR-105422CR-105423
Nombre de la actividad
ActivityName
El nombre del evento o la tarea específicos que tuvieron lugar en un momento determinado dentro del proceso de gestión de cambios.
Descripción

El nombre de la actividad describe un paso o hito específico del ciclo de vida de una solicitud de cambio, como «Change Submitted For Assessment» o «Change Approved by CAB». Estas actividades forman los nodos del mapa de procesos descubierto.

En el análisis, este atributo es fundamental para visualizar el flujo del proceso, identificar la secuencia de eventos y detectar desviaciones del procedimiento estándar. Se utiliza para calcular los tiempos de transición entre actividades y comprender dónde se producen los retrasos.

Por qué es importante

Este atributo es fundamental para descubrir y visualizar el flujo real del proceso, ya que permite identificar cuellos de botella, ciclos de retrabajo y rutas que no cumplen las normas.

Dónde obtenerlo

Se genera a partir de cambios de estado, entradas de diario o registros de eventos específicos relacionados con el objeto Change Request en Ivanti Cherwell.

Ejemplos
Cambio enviado para evaluaciónCambio pendiente de aprobaciónCambio implementado
Sistema de origen
SourceSystem
El sistema de registro del que se extrajeron los datos. En esta vista, será «Ivanti Cherwell».
Descripción

Este atributo identifica el sistema de origen de los datos de eventos. En entornos heterogéneos, ayuda a distinguir los datos procedentes de distintas fuentes. En este modelo de datos específico, tendrá un valor constante que indica que los datos proceden de Ivanti Cherwell.

Aunque pueda parecer estático en un modelo de una sola fuente, es fundamental para la gobernanza de datos, la trazabilidad y futuras integraciones con otros sistemas. Garantiza la claridad sobre la procedencia de los datos y ayuda a gestionar su calidad.

Por qué es importante

Proporciona un contexto esencial sobre el origen de los datos, fundamental para la gobernanza de datos, la resolución de problemas y la trazabilidad.

Dónde obtenerlo

Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos para identificar el origen del conjunto de datos.

Ejemplos
Ivanti Cherwell
Última actualización de datos
LastDataUpdate
La marca de tiempo que indica cuándo se extrajeron o actualizaron por última vez los datos de este evento desde el sistema de origen.
Descripción

Este atributo registra la fecha y hora en que se obtuvieron por última vez los datos de Ivanti Cherwell. No representa un evento del proceso, sino metadatos sobre la actualidad de los datos.

Es importante para que las personas usuarias de los Dashboards sepan qué tan actual es el análisis. Ayuda a gestionar los calendarios de actualización y garantiza que las decisiones se basen en datos cuya antigüedad se conoce.

Por qué es importante

Indica la actualidad de los datos, un aspecto fundamental para que los usuarios confíen en el análisis y comprendan su relevancia respecto al estado actual de las operaciones.

Dónde obtenerlo

Esta marca de tiempo se genera y se añade a cada registro durante el proceso de extracción, transformación y carga (ETL) de datos.

Ejemplos
2024-05-21T02:00:00Z
Equipo responsable del cambio
ChangeTeam
El equipo o grupo responsable actualmente de la solicitud de cambio.
Descripción

El equipo responsable del cambio es el grupo o departamento asignado a la solicitud. Al igual que el responsable del cambio, puede cambiar durante el proceso, lo que indica una transferencia de responsabilidad entre equipos, por ejemplo, del centro de atención al usuario a un equipo de ingeniería de redes.

Este atributo es esencial para analizar los traspasos entre equipos e identificar retrasos sistémicos causados por equipos concretos. Ayuda a responder qué equipos están sobrecargados o dónde se producen fallos de comunicación, y respalda directamente el análisis «Change Handoff & Resource Utilization».

Por qué es importante

Identifica la responsabilidad a nivel de equipo, un aspecto clave para analizar los cuellos de botella del proceso, medir el rendimiento de los equipos y comprender los retrasos en los traspasos entre grupos.

Dónde obtenerlo

Esta información suele almacenarse en el campo «Owned By Team» o en un campo similar de asignación de grupos del objeto Change Request.

Ejemplos
Operaciones de redAdministración de bases de datosSoporte de aplicaciones
Estado del cambio
ChangeStatus
El estado actual o final de la solicitud de cambio, como «Closed», «Rejected» o «In Progress».
Descripción

El estado del cambio indica la situación de una solicitud de cambio en un momento determinado o su resultado final. Es un atributo fundamental para comprender la resolución de los casos e identificar excepciones.

En el análisis de procesos, este atributo se utiliza para filtrar resultados específicos, como analizar únicamente los cambios rechazados o cancelados. Alimenta KPI como Change Request Rejection Rate y es esencial para comprender la salud y eficiencia generales del proceso de gestión de cambios.

Por qué es importante

Define el resultado de una solicitud de cambio y permite realizar análisis clave sobre las tasas de rechazo y finalización, así como sobre la distribución de casos abiertos y cerrados.

Dónde obtenerlo

Corresponde al campo «Status» del objeto de negocio Change Request en Ivanti Cherwell.

Ejemplos
AprobadoRechazadoCerradoCanceladoA la espera de aprobación
Fecha objetivo de finalización
TargetCompletionDate
La fecha límite planificada o acordada para completar la implementación del cambio.
Descripción

La fecha objetivo de finalización es la fecha y hora en las que se espera que el cambio esté completamente implementado y verificado. A menudo forma parte de un Acuerdo de Nivel de Servicio (SLA) y sirve como referencia principal para medir el rendimiento.

Este atributo es esencial para supervisar la puntualidad y el cumplimiento de los plazos. Se compara con la fecha real de finalización para calcular los KPI On-Time Change Completion Rate y Change SLA Adherence Rate. Ayuda a identificar de forma proactiva los cambios que corren el riesgo de no cumplir sus objetivos.

Por qué es importante

Proporciona la referencia para medir el rendimiento puntual y el cumplimiento de los SLA, indicadores fundamentales de la eficiencia y fiabilidad del proceso.

Dónde obtenerlo

Normalmente es un campo de fecha específico del objeto Change Request, a menudo denominado «Target Date», «Due Date» o «SLA Target».

Ejemplos
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Nivel de riesgo del cambio
ChangeRiskLevel
El nivel de riesgo evaluado asociado al cambio, como «Low», «Medium» o «High».
Descripción

El nivel de riesgo del cambio es una clasificación asignada durante la fase de evaluación para cuantificar el posible impacto negativo de un cambio. Esta evaluación suele influir en el proceso de aprobación y en el nivel de revisión necesario.

En Process Mining, este atributo se utiliza para analizar la coherencia de las evaluaciones de riesgos y relacionar el riesgo con el comportamiento del proceso. Por ejemplo, permite comprobar si los cambios de alto riesgo siguen una ruta de aprobación más rigurosa o si tienen tiempos de implementación más largos. Respalda directamente el panel «Change Risk Assessment Consistency».

Por qué es importante

Permite analizar cómo influye el riesgo en el flujo del proceso, los ciclos de aprobación y las tasas de éxito, y ayuda a garantizar que los cambios de alto riesgo reciban la revisión adecuada.

Dónde obtenerlo

Este valor se almacena en un campo «Risk Level» o similar del objeto Change Request, que normalmente se completa durante la actividad de evaluación de riesgos.

Ejemplos
BajoMedioAltoCrítico
Responsable del cambio
ChangeOwner
El usuario o la persona responsable actualmente de la solicitud de cambio.
Descripción

El responsable del cambio es la persona asignada y responsable de la solicitud en una fase concreta. Este atributo suele cambiar a medida que la solicitud avanza por su ciclo de vida, lo que indica un traspaso entre personas.

Analizar al responsable del cambio ayuda a comprender la carga de trabajo de los recursos e identificar cuellos de botella relacionados con personas concretas. También es fundamental para analizar los traspasos, que pueden ser una fuente importante de retrasos. Este atributo respalda el panel «Change Handoff & Resource Utilization».

Por qué es importante

Registra la responsabilidad individual y permite analizar la distribución de la carga de trabajo, la frecuencia de los traspasos y los cuellos de botella específicos de los recursos.

Dónde obtenerlo

Normalmente corresponde al campo «Owned By» o «Assigned To» del objeto de negocio Change Request.

Ejemplos
Alice JohnsonBob WilliamsCharlie Brown
Tipo de cambio
ChangeType
La clasificación del cambio, como «Standard», «Normal» o «Emergency».
Descripción

El tipo de cambio categoriza la solicitud según su naturaleza, urgencia e impacto. Los tipos habituales incluyen Standard (preaprobado y de bajo riesgo), Normal (requiere una evaluación y aprobación completas) y Emergency (requiere una implementación inmediata).

Este atributo permite realizar análisis segmentados para comparar el rendimiento del proceso entre distintas categorías. Por ejemplo, ayuda a determinar si los cambios de emergencia siguen una ruta diferente y más rápida, o si los cambios estándar se procesan realmente con una fricción mínima. Es clave para el panel «Problematic Change Type Performance».

Por qué es importante

Segmentar el proceso por tipo de cambio es fundamental para comparar el rendimiento e identificar si categorías específicas, como «Emergency», provocan cuellos de botella o desviaciones.

Dónde obtenerlo

Corresponde a un campo de clasificación, probablemente denominado «Change Type» o «Category», en el objeto de negocio Change Request.

Ejemplos
EstándarNormalEmergencia
Fecha real de finalización
ActualCompletionDate
La fecha y hora en que el cambio se implementó realmente y se verificó como completado.
Descripción

La fecha real de finalización marca el momento en que terminó el trabajo de implementación de la solicitud de cambio. Es un hito clave que se compara con el plazo planificado para medir el rendimiento.

Este atributo se utiliza junto con la fecha objetivo de finalización para determinar si un cambio se completó a tiempo. Es un dato fundamental para calcular KPI como On-Time Change Completion Rate y analizar las causas de los retrasos en la fase de implementación.

Por qué es importante

Registra el momento real de finalización, necesario para calcular las tasas de entrega puntual y analizar la magnitud de los retrasos.

Dónde obtenerlo

Esta fecha suele registrarse cuando el estado de la solicitud de cambio pasa a «Implemented» o «Completed». Puede corresponder a un campo específico o inferirse de la marca de tiempo de ese cambio de estado.

Ejemplos
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
Finalización puntual
IsOnTimeCompletion
Un indicador calculado que es verdadero si el cambio se completó en la fecha objetivo o antes.
Descripción

Es un atributo booleano derivado de la comparación entre «ActualCompletionDate» y «TargetCompletionDate». Simplifica el análisis al proporcionar un indicador binario claro del cumplimiento de los plazos para cada solicitud de cambio.

Este indicador constituye la base para calcular el KPI «On-Time Change Completion Rate». Puede utilizarse como filtro en los Dashboards para aislar y analizar fácilmente los cambios retrasados, lo que ayuda a identificar las causas raíz más frecuentes de los retrasos.

Por qué es importante

Simplifica el análisis del rendimiento al proporcionar un resultado claro de éxito o incumplimiento respecto a los plazos y alimenta directamente los KPI de finalización puntual.

Dónde obtenerlo

Este atributo no existe en el sistema de origen. Se calcula durante la transformación de datos comparando «ActualCompletionDate» <= «TargetCompletionDate».

Ejemplos
truefalse
Motivo del rechazo
ChangeRejectionReason
Una descripción textual o categoría que explica por qué se rechazó una solicitud de cambio.
Descripción

Cuando se rechaza una solicitud de cambio, este atributo registra el motivo proporcionado por la persona aprobadora. Puede seleccionarse de una lista predefinida o introducirse como una explicación de texto libre.

Esta información es fundamental para el panel «Rejected Change Request Analysis». Al categorizar y analizar los motivos de rechazo, las organizaciones pueden identificar problemas habituales en las solicitudes de cambio, como información incompleta, una evaluación de riesgos inadecuada o conflictos empresariales. Estos conocimientos pueden utilizarse para mejorar la calidad de futuras solicitudes de cambio.

Por qué es importante

Proporciona información directa sobre por qué fallan los cambios y permite introducir mejoras específicas en el proceso de envío y evaluación para reducir la tasa general de rechazo.

Dónde obtenerlo

Estos datos suelen capturarse en un campo específico «Rejection Reason» o en un campo de notas que se completa cuando el estado cambia a «Rejected».

Ejemplos
Detalles insuficientes en el plan de implementaciónEvaluación de riesgos incompletaEn conflicto con otros cambios programados
Persona solicitante del cambio
ChangeSubmitter
El usuario que creó o envió inicialmente la solicitud de cambio.
Descripción

Este atributo identifica a la persona que inició la solicitud de cambio. Puede ser distinta del responsable del cambio, que asumirá la responsabilidad de su implementación más adelante en el proceso.

Analizar a la persona solicitante del cambio puede ayudar a identificar patrones relacionados con la calidad de las solicitudes. Por ejemplo, podría revelar que determinadas personas o equipos envían con frecuencia solicitudes incompletas que provocan rechazos o retrabajo. Esta información puede utilizarse para ofrecer formación específica y mejorar la calidad general de las solicitudes.

Por qué es importante

Ayuda a rastrear el origen de las solicitudes de cambio, permite analizar la calidad de los envíos por persona o equipo e identificar oportunidades de formación.

Dónde obtenerlo

Normalmente corresponde al campo «Created By» o «Requested By» del objeto Change Request.

Ejemplos
Susan MillerDavid ChenMaria Garcia
Prioridad del cambio
ChangePriority
El nivel de prioridad de la solicitud de cambio, que indica su urgencia e impacto empresarial.
Descripción

La prioridad del cambio es una clasificación determinada al combinar la urgencia y el impacto de un cambio. Ayuda a los equipos a priorizar el trabajo y asignar recursos de forma eficaz, garantizando que los cambios más críticos se atiendan primero.

En el análisis, la prioridad permite comprobar si los cambios de alta prioridad se procesan más rápido que los de baja prioridad. Cualquier desviación de esta expectativa podría indicar ineficiencias o cuellos de botella en el proceso de priorización o ejecución.

Por qué es importante

Ayuda a analizar si el proceso prioriza correctamente los cambios de alto impacto y si estos realmente se aceleran como estaba previsto.

Dónde obtenerlo

Normalmente es un campo denominado «Priority» en el objeto Change Request. Puede establecerse manualmente o derivarse de los campos de impacto y urgencia.

Ejemplos
1 - Crítico2 - Alto3 - Medio4 - Bajo
Servicio afectado
ServiceAffected
El servicio empresarial principal o elemento de configuración (CI) afectado por el cambio.
Descripción

Este atributo identifica el servicio de TI, la aplicación o el componente de infraestructura principal al que se dirige la solicitud de cambio. Vincula el proceso de gestión de cambios con el contexto más amplio de la gestión de servicios de TI.

Analizar por servicio afectado es fundamental para el KPI «Top Problematic Change Types», ya que ayuda a identificar qué servicios experimentan cambios con mayor frecuencia y cuáles están asociados a tasas elevadas de rechazo o retrasos. Esto proporciona información valiosa a los responsables de los servicios para mejorar la estabilidad y gestionar la deuda técnica.

Por qué es importante

Vincula los cambios con servicios empresariales específicos y permite identificar qué servicios son más inestables o generan más cambios problemáticos.

Dónde obtenerlo

Normalmente se vincula desde la Base de Datos de Gestión de la Configuración (CMDB) y se almacena en un campo «Primary CI» o «Service» del objeto Change Request.

Ejemplos
Servicio de correo electrónico (Exchange)Sistema ERP (SAP)Switch de red principal (CISCO-4500X)
Tiempo del ciclo de implementación
ImplementationCycleTime
La duración calculada desde el inicio de la implementación de un cambio hasta su finalización.
Descripción

Esta métrica cuantifica el tiempo empleado en la fase de implementación del cambio. Se calcula como la duración entre las actividades «Change Implementation Started» y «Change Implemented».

Este atributo se utiliza para calcular el KPI Average Change Implementation Time y respalda el panel «Change Implementation Flow & Delays». Ayuda a distinguir los retrasos de planificación de los retrasos de ejecución, para que los equipos puedan centrar las mejoras en el trabajo de implementación técnica.

Por qué es importante

Aísla el rendimiento de la fase real de implementación y ayuda a identificar cuellos de botella técnicos o relacionados con los recursos, separados de los retrasos de aprobación.

Dónde obtenerlo

Se calcula en la herramienta de Process Mining o durante la transformación de datos, obteniendo la diferencia de tiempo entre las marcas de tiempo de los eventos de inicio y finalización de la implementación.

Ejemplos
4 horas 15 minutos1 día 2 horas30 minutos
Unidad de negocio
BusinessUnit
La unidad de negocio o el departamento que solicitó el cambio o se beneficiará de él.
Descripción

Este atributo asocia la solicitud de cambio con una parte concreta de la organización, como «Finance», «Marketing» u «Operations». Proporciona contexto empresarial a un proceso que, de otro modo, sería principalmente técnico.

Analizar por unidad de negocio permite saber de dónde procede la demanda de cambios. Puede ayudar en los modelos de imputación de costes, a comprender el impacto de los cambios de TI en distintas funciones empresariales y a identificar si determinadas unidades tienen cambios más complejos o lentos que otras.

Por qué es importante

Proporciona contexto empresarial y permite analizar la demanda, el impacto y el rendimiento de los cambios desde una perspectiva organizativa.

Dónde obtenerlo

Puede ser un campo del objeto Change Request o heredarse del perfil de usuario de la persona solicitante.

Ejemplos
FinanzasRecursos humanosVentas y marketingOperaciones
Obligatorio Recomendado Opcional

Actividades de gestión de cambios

Estos son los pasos y los hitos clave del proceso que debe capturar en su registro de eventos para descubrir el proceso con precisión y medir su rendimiento.
7 Recomendado 7 Opcional
Actividad Descripción
Cambio aprobado por el CAB
Un hito clave en el que el Change Advisory Board (CAB) o la autoridad designada aprueba que el cambio siga adelante. Se infiere cuando el estado de la solicitud de cambio se actualiza a «Approved».
Por qué es importante

Esta actividad marca el punto final para medir el tiempo del ciclo de aprobación. Desbloquea el proceso, permite iniciar la planificación y la implementación, y es fundamental para el KPI Change Approval Cycle Time.

Dónde obtenerlo

Se infiere del historial de auditoría del objeto Change Request, concretamente de la marca de tiempo en la que el campo «Status» cambia a «Approved».

Recopilar

Se infiere del cambio de estado a «Approved».

Tipo de evento inferred
Cambio cerrado
Esta actividad es el punto final satisfactorio del proceso de gestión de cambios. Se registra cuando el estado de la solicitud de cambio se establece en «Closed», lo que indica que todo el trabajo ha finalizado.
Por qué es importante

Como principal punto final de éxito, esta actividad es esencial para calcular el tiempo del ciclo de extremo a extremo de los cambios completados correctamente. Confirma que todos los pasos del proceso han concluido.

Dónde obtenerlo

Se infiere de la marca de tiempo del cambio de estado final a «Closed» en el historial de auditoría del objeto Change Request.

Recopilar

Se infiere del cambio de estado final a «Closed».

Tipo de evento inferred
Cambio implementado
Este hito indica que el trabajo técnico del cambio ha finalizado. Se registra cuando el estado de la solicitud de cambio se actualiza a «Implemented» o a un estado similar pendiente de verificación.
Por qué es importante

Este es un hito crítico de éxito y un dato clave para los KPI On-Time Change Completion Rate y Average Change Implementation Time. Marca el final de la fase de ejecución.

Dónde obtenerlo

Se infiere del registro de auditoría del objeto Change Request, utilizando la marca de tiempo del cambio de estado a «Implemented» o «Pending Verification».

Recopilar

Se infiere del cambio de estado a «Implemented».

Tipo de evento inferred
Cambio programado
Esta actividad marca el momento en que la fecha y hora de implementación del cambio se confirman y registran formalmente. Se registra cuando el estado se actualiza a «Scheduled».
Por qué es importante

Este es un hito clave de compromiso. Transforma el cambio de una idea aprobada en una acción planificada y es un requisito previo para la implementación.

Dónde obtenerlo

Se infiere del historial del objeto Change Request, capturando la marca de tiempo en la que el campo «Status» se actualiza a «Scheduled».

Recopilar

Se infiere del cambio de estado a «Scheduled».

Tipo de evento inferred
Impacto y riesgo evaluados
Esta actividad indica que se ha completado el análisis de riesgos e impacto de la solicitud de cambio. Normalmente se infiere cuando el estado de la solicitud pasa a una fase que indica que está lista para su aprobación, como «Awaiting Approval».
Por qué es importante

El seguimiento de esta actividad ayuda a medir la duración de la fase de evaluación y garantiza que el análisis de riesgos se realice de forma sistemática antes de la aprobación, lo que respalda el KPI de tasa de cumplimiento de la evaluación de riesgos.

Dónde obtenerlo

Se infiere del historial del objeto Change Request. Se registra en la marca de tiempo en la que el campo «Status» se actualiza de «Assessing» a un estado como «Awaiting CAB Approval».

Recopilar

Se infiere del cambio de estado a «Awaiting CAB Approval».

Tipo de evento inferred
Revisión posterior a la implementación realizada
Esta actividad indica que se ha realizado una revisión formal del cambio completado para evaluar su éxito y recoger las lecciones aprendidas. A menudo se infiere mediante un cambio de estado a «Post Implementation Review».
Por qué es importante

Su seguimiento garantiza que el ciclo de retroalimentación de los cambios se cierre. Es esencial para la mejora continua y respalda directamente el KPI Post-Implementation Review Rate.

Dónde obtenerlo

Se infiere del historial de auditoría del objeto Change Request, capturando la marca de tiempo en la que «Status» pasa a un estado como «Post Implementation Review».

Recopilar

Se infiere del cambio de estado a «Post Implementation Review».

Tipo de evento inferred
Solicitud de cambio creada
Esta actividad marca el inicio de una nueva solicitud de cambio en el sistema. Normalmente se registra cuando se crea un nuevo registro en el objeto de negocio Change Request, que establece el punto de partida de todo el proceso.
Por qué es importante

Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta otras permite conocer la duración total del ciclo de vida e identificar retrasos en las primeras etapas.

Dónde obtenerlo

Este evento se obtiene de la marca de tiempo de creación del registro Change Request. En Ivanti Cherwell, normalmente se almacena en el campo «CreatedDateTime» del objeto de negocio Change Request.

Recopilar

Se obtiene directamente de la marca de tiempo de creación del registro.

Tipo de evento explicit
Cambio cancelado
Representa un estado final en el que una solicitud de cambio aprobada o en curso se retira antes de completarse. Este evento se registra cuando el estado se actualiza a «Cancelled».
Por qué es importante

Este es un punto final alternativo del proceso. Analizar por qué y cuándo se cancelan los cambios puede revelar problemas de planificación, asignación de recursos o cambios en las prioridades del negocio.

Dónde obtenerlo

Se infiere del historial de auditoría, capturando la marca de tiempo en la que el campo «Status» del objeto Change Request se actualiza a «Cancelled».

Recopilar

Se infiere del cambio de estado a «Cancelled».

Tipo de evento inferred
Cambio enviado para evaluación
Representa el envío formal de una solicitud de cambio recién creada para su evaluación inicial. Por lo general, se infiere cuando el estado de la solicitud pasa de «New» o «Draft» a un estado como «Assessing».
Por qué es importante

Esta actividad marca el inicio del proceso formal de cambios después de introducir los datos iniciales. El tiempo transcurrido entre la creación y el envío puede indicar necesidades de formación de los usuarios o fricciones en el proceso.

Dónde obtenerlo

Se infiere del registro de auditoría o del historial del objeto Change Request, identificando la marca de tiempo en la que el campo «Status» cambia a un valor como «Assessing» o «Submitted».

Recopilar

Se infiere del cambio de estado de «New» a «Assessing».

Tipo de evento inferred
Cambio pendiente de aprobación
Esta actividad representa el periodo en el que una solicitud de cambio está formalmente pendiente de una decisión del Change Advisory Board (CAB) u otra autoridad de aprobación. Se infiere a partir de un estado como «Pending Approval» o «Awaiting CAB».
Por qué es importante

Esta es una actividad crítica de tiempo de espera. Analizar su duración ayuda a identificar cuellos de botella en el Workflow de aprobación, una fuente habitual de retrasos en la Gestión de cambios.

Dónde obtenerlo

Se obtiene de la marca de tiempo en la que el campo «Status» del objeto de negocio Change Request se actualiza a «Pending Approval» o a un valor equivalente.

Recopilar

Se identifica mediante la entrada en el estado «Pending Approval».

Tipo de evento inferred
Cambio rechazado
Esta actividad representa la decisión final de rechazar la solicitud de cambio durante la fase de aprobación. Se registra cuando el estado de la solicitud de cambio se establece en «Rejected».
Por qué es importante

Este es un punto final crítico de fallo. Analizar los cambios rechazados y sus motivos ayuda a mejorar la calidad de las solicitudes iniciales y respalda el KPI Change Request Rejection Rate.

Dónde obtenerlo

Se infiere de la marca de tiempo en la que el campo «Status» del objeto Change Request se actualiza a «Rejected» en el historial de auditoría.

Recopilar

Se infiere del cambio de estado a «Rejected».

Tipo de evento inferred
Implementación del cambio iniciada
Representa el inicio de la ejecución técnica del cambio. Normalmente se infiere cuando el estado de la solicitud de cambio pasa a «In Progress» o «Implementing».
Por qué es importante

Esta actividad marca el inicio de la ventana de implementación. El tiempo entre este punto y «Change Implemented» corresponde a la duración real de la implementación, un componente clave del tiempo total del ciclo.

Dónde obtenerlo

Se infiere del historial de auditoría del objeto Change Request. Es la marca de tiempo en la que el campo «Status» se actualiza a un valor como «In Progress» o «Implementing».

Recopilar

Se infiere del cambio de estado a «In Progress».

Tipo de evento inferred
Plan de implementación desarrollado
Marca la finalización de la planificación detallada del cambio, incluida la definición de tareas, recursos y planes de reversión. A menudo se infiere cuando el cambio pasa de «Approved» a «Scheduled».
Por qué es importante

La duración de esta actividad muestra la eficiencia de la fase de planificación del cambio. Los retrasos en este punto pueden afectar al calendario general del cambio, incluso después de obtener la aprobación.

Dónde obtenerlo

Puede inferirse de la marca de tiempo de un cambio de estado de «Approved» a «Scheduled». Como alternativa, puede vincularse a la cumplimentación de campos de planificación específicos.

Recopilar

Se infiere del cambio de estado de «Approved» a «Scheduled».

Tipo de evento inferred
Verificación del cambio realizada
Representa la fase de pruebas y validación para confirmar que el cambio se realizó correctamente y no provocó efectos adversos. Se infiere de un cambio de estado a «Verification» o «Testing».
Por qué es importante

Analizar la frecuencia y duración de esta actividad garantiza que no se omitan los pasos de aseguramiento de la calidad. Es un paso esencial para prevenir incidentes provocados por cambios.

Dónde obtenerlo

Se registra a partir de la marca de tiempo de un cambio de estado en el objeto Change Request, como el paso a un estado «Verification» o «User Acceptance Testing».

Recopilar

Se infiere del cambio de estado a «Verification».

Tipo de evento inferred
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Ivanti Cherwell

¿Listo para comenzar?

Utilice esta plantilla para iniciar el análisis de su proceso de Change Management y conseguir mejoras significativas. Comience hoy su camino hacia actualizaciones optimizadas y más eficientes.

Garantice un 95 % de éxito en los cambios: optimice Ivanti Cherwell ahora

Elimine los cuellos de botella, reduzca los riesgos y alcance un 95 % de éxito en los cambios.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Comience al instante.