Su Template de datos de Change Management
Su Template de datos de Change Management
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía de extracción desde Ivanti Cherwell
Atributos de la gestión de cambios
| 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
|
|||
Actividades de gestión de cambios
| 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
|
|||
Guías de extracción
¿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.
No necesita tarjeta de crédito. Comience al instante.