Su Template de datos de gestión de cambios
Su Template de datos de gestión de cambios
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Instrucciones para extraer datos de Ivanti Cherwell
Atributos de gestión de cambios
| Nombre | Descripción | ||
|---|---|---|---|
|
Hora del evento
EventTime
|
Marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específico 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 todos los análisis de Process Mining basados en el tiempo. Este atributo se utiliza para calcular la duración entre actividades, medir el tiempo de ciclo total de los casos e identificar tiempos de espera o demoras en el proceso. Es fundamental para crear Dashboards que supervisen el rendimiento frente a objetivos temporales, como el tiempo de ciclo de aprobación de cambios.
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
Suele encontrarse en los registros de cambios de estado, los historiales de auditoría o las marcas de tiempo de las entradas del 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 solicitud de cambio
ChangeRequestId
|
Identificador único de una solicitud de cambio, que agrupa todas las actividades relacionadas desde su inicio hasta su cierre. | ||
|
Descripción
El ID de solicitud de cambio es la clave principal que identifica de forma única cada iniciativa de cambio durante todo su ciclo de vida. En Process Mining, sirve como identificador del caso y vincula en una sola instancia del proceso todos los eventos, como el envío, la evaluación, la aprobación y la implementación. Analizar los datos mediante el ID de solicitud de cambio permite obtener una visión integral del proceso de gestión de cambios. Así se pueden seguir los cambios individuales, calcular los tiempos de ciclo totales e identificar desviaciones del proceso o cuellos de botella específicos de cada solicitud.
Por qué es importante
Este identificador esencial del caso conecta todos los eventos relacionados y permite seguir todo el recorrido de una solicitud de cambio y analizar su rendimiento.
Dónde obtenerlo
Suele ser el identificador principal del objeto de negocio Change Request en Ivanti Cherwell.
Ejemplos
CR-105421CR-105422CR-105423
|
|||
|
Nombre de la actividad
ActivityName
|
Nombre del evento o la tarea específica que tuvo lugar en un momento determinado 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 'Cambio enviado para evaluación' o 'Cambio aprobado por el 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 entender dónde se producen las demoras.
Por qué es importante
Este atributo es fundamental para descubrir y visualizar el flujo real del proceso, lo que permite identificar cuellos de botella, ciclos de retrabajo y rutas que no cumplen con los requisitos.
Dónde obtenerlo
Se genera a partir de cambios de estado, entradas del diario o registros de eventos específicos relacionados con el objeto Change Request en Ivanti Cherwell.
Ejemplos
Solicitud de cambio enviada para evaluaciónCambio en espera de aprobaciónCambio implementado
|
|||
|
Sistema de origen
SourceSystem
|
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, tiene un valor constante que indica que los datos provienen de Ivanti Cherwell. Aunque en un modelo con una sola fuente pueda parecer un dato estático, es fundamental para la gobernanza de datos, la trazabilidad y las futuras integraciones con otros sistemas. Aclara la procedencia de los datos y facilita la gestión de su calidad.
Por qué es importante
Aporta contexto esencial sobre el origen de los datos, algo fundamental para la gobernanza de datos, la resolución de problemas y la trazabilidad.
Dónde obtenerlo
Suele ser un valor estático que se añade durante la extracción y transformación de los datos para identificar el origen del conjunto de datos.
Ejemplos
Ivanti Cherwell
|
|||
|
Última actualización de los datos
LastDataUpdate
|
Marca de tiempo que indica cuándo se extrajeron o actualizaron por última vez del sistema de origen los datos de este evento. | ||
|
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 que es metadato sobre la actualidad de los datos. Esta información permite a quienes consultan el Dashboard saber qué tan recientes son los datos del análisis. También 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 qué tan recientes son los datos, algo fundamental para que las personas usuarias confíen en el análisis y entiendan su relevancia para el estado actual de las operaciones.
Dónde obtenerlo
Esta marca de tiempo se genera y se asigna a cada registro durante el proceso de extracción, transformación y carga (ETL) de los datos.
Ejemplos
2024-05-21T02:00:00Z
|
|||
|
Equipo responsable del cambio
ChangeTeam
|
Equipo o grupo actualmente responsable de la solicitud de cambio. | ||
|
Descripción
El equipo responsable del cambio es el grupo o departamento al que se asigna la solicitud. Al igual que el responsable individual, puede cambiar durante el proceso, lo que indica un traspaso de responsabilidad entre equipos, por ejemplo, de la mesa de ayuda a un equipo de ingeniería de redes. Este atributo es esencial para analizar los traspasos entre equipos e identificar demoras sistémicas causadas por equipos específicos. Ayuda a determinar qué equipos están sobrecargados o dónde se producen fallas de comunicación, y sirve directamente de base para el análisis de traspasos de cambios y utilización de recursos.
Por qué es importante
Identifica quién es responsable a nivel de equipo, un dato clave para analizar los cuellos de botella del proceso, medir el rendimiento de los equipos y entender las demoras 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 grupo del objeto Change Request.
Ejemplos
Operaciones de redAdministración de bases de datosSoporte de aplicaciones
|
|||
|
Estado del cambio
ChangeStatus
|
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 en un momento determinado o su resultado final. Es un atributo fundamental para entender la resolución de los casos e identificar excepciones. En el análisis de procesos, este atributo se utiliza para filtrar resultados específicos, por ejemplo, para analizar solo los cambios rechazados o cancelados. Permite calcular KPI como la tasa de rechazo de solicitudes de cambio y es esencial para entender la salud y la eficiencia generales del proceso de gestión de cambios.
Por qué es importante
Define el resultado de una solicitud de cambio y permite analizar aspectos clave como las tasas de rechazo y finalización, así como la distribución de los casos abiertos y cerrados.
Dónde obtenerlo
Corresponde al campo 'Status' del objeto de negocio Change Request en Ivanti Cherwell.
Ejemplos
AprobadoRechazadoCerradoCanceladoPendiente de aprobación
|
|||
|
Fecha objetivo de finalización
TargetCompletionDate
|
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 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 de tasa de finalización puntual de cambios y tasa de cumplimiento de los SLA de cambios. También ayuda a identificar de forma proactiva los cambios que corren el riesgo de no alcanzar sus objetivos.
Por qué es importante
Proporciona la referencia para medir la puntualidad y el cumplimiento de los SLA, indicadores clave de la eficiencia y fiabilidad del proceso.
Dónde obtenerlo
Suele ser un campo de fecha específico del objeto Change Request, denominado a menudo '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
|
Nivel de riesgo asignado al cambio, como 'Bajo', 'Medio' o 'Alto'. | ||
|
Descripción
El nivel de riesgo del cambio es una clasificación que se asigna 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 tardan más en implementarse. Sirve directamente de base para el Dashboard de coherencia en la evaluación de riesgos de cambios.
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 denominado 'Risk Level' o similar del objeto Change Request y suele completarse durante la actividad de evaluación de riesgos.
Ejemplos
BajoMedioAltoCrítico
|
|||
|
Responsable del cambio
ChangeOwner
|
Usuario o persona actualmente responsable de la solicitud de cambio. | ||
|
Descripción
El responsable del cambio es la persona a quien se asigna la solicitud y que debe responder por ella en una etapa determinada. Este atributo suele cambiar a medida que la solicitud avanza en su ciclo de vida, lo que indica un traspaso entre personas. Analizar quién es responsable del cambio ayuda a entender la carga de trabajo de los recursos e identificar cuellos de botella relacionados con personas específicas. También es fundamental para analizar los traspasos, que pueden causar demoras importantes. Este atributo sirve de base para el Dashboard de traspasos de cambios y utilización de recursos.
Por qué es importante
Registra quién es responsable en cada caso y permite analizar la distribución de la carga de trabajo, la frecuencia de los traspasos y los cuellos de botella relacionados con recursos específicos.
Dónde obtenerlo
Suele corresponder al campo 'Owned By' o 'Assigned To' del objeto de negocio Change Request.
Ejemplos
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Tipo de cambio
ChangeType
|
Clasificación del cambio, como 'Estándar', 'Normal' o 'De emergencia'. | ||
|
Descripción
El tipo de cambio clasifica la solicitud según su naturaleza, urgencia e impacto. Entre los tipos habituales se encuentran Estándar (preaprobado y de bajo riesgo), Normal (requiere una evaluación y aprobación completas) y De emergencia (requiere implementación inmediata). Este atributo permite segmentar el análisis y comparar el rendimiento del proceso entre distintas categorías. Por ejemplo, ayuda a determinar si los cambios de emergencia siguen una ruta distinta y más rápida, o si los cambios estándar se procesan realmente con pocas dificultades. Es clave para el Dashboard de rendimiento de los tipos de cambio problemáticos.
Por qué es importante
Segmentar el proceso por tipo de cambio es fundamental para comparar el rendimiento y determinar si ciertas categorías, como 'De emergencia', provocan cuellos de botella o desviaciones.
Dónde obtenerlo
Corresponde a un campo de clasificación del objeto de negocio Change Request, probablemente denominado 'Change Type' o 'Category'.
Ejemplos
EstándarNormalDe emergencia
|
|||
|
Fecha real de finalización
ActualCompletionDate
|
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 la fecha límite planificada 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 la tasa de finalización puntual de cambios y analizar las causas de las demoras en la fase de implementación.
Por qué es importante
Registra la hora real de finalización, necesaria para calcular las tasas de cumplimiento de los plazos y analizar la magnitud de las demoras.
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
|
Indicador calculado que es verdadero si el cambio se completó en la fecha prevista o antes. | ||
|
Descripción
Este atributo booleano se obtiene al comparar 'ActualCompletionDate' con 'TargetCompletionDate'. Simplifica el análisis al ofrecer un indicador claro, con dos posibles valores, del cumplimiento de los plazos de cada solicitud de cambio. Este indicador sirve de base para calcular el KPI «Tasa de finalización de cambios a tiempo». Puede utilizarse como filtro en los Dashboards para identificar y analizar fácilmente los cambios tardíos, lo que ayuda a encontrar las causas habituales de los retrasos.
Por qué es importante
Facilita el análisis del rendimiento al indicar claramente si se cumplieron los plazos y permite calcular directamente los KPI de finalización a tiempo.
Dónde obtenerlo
Este atributo no está en el sistema de origen. Se calcula durante la transformación de datos comparando 'ActualCompletionDate' <= 'TargetCompletionDate'.
Ejemplos
truefalse
|
|||
|
Motivo del rechazo
ChangeRejectionReason
|
Descripción 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 indicado por quien la aprobó. Puede seleccionarse de una lista predefinida o escribirse como texto libre. Esta información es fundamental para el Dashboard de análisis de solicitudes de cambio rechazadas. Al clasificar 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 insuficiente o conflictos con el negocio. Esta información puede servir para mejorar la calidad de futuras solicitudes de cambio.
Por qué es importante
Permite entender directamente por qué no prosperan los cambios y aplicar mejoras específicas al proceso de envío y evaluación para reducir la tasa general de rechazo.
Dónde obtenerlo
Estos datos suelen registrarse 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 incompletaConflictos con otros cambios programados
|
|||
|
Prioridad del cambio
ChangePriority
|
Nivel de prioridad de la solicitud de cambio, que indica su urgencia e impacto en el negocio. | ||
|
Descripción
La prioridad del cambio se determina combinando la urgencia y el impacto del cambio. Ayuda a los equipos a priorizar el trabajo y asignar los recursos de forma eficaz para atender primero los cambios más críticos. El análisis de la prioridad permite comprobar si los cambios de alta prioridad se procesan más rápido que los de baja prioridad. Cualquier diferencia respecto a lo esperado podría indicar ineficiencias o cuellos de botella en la priorización o la ejecución.
Por qué es importante
Ayuda a analizar si el proceso prioriza correctamente los cambios de mayor impacto y si estos se aceleran como estaba previsto.
Dónde obtenerlo
Suele ser 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
|
Servicio de negocio 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 panorama general de la gestión de servicios de TI. Analizar los datos por servicio afectado es fundamental para el KPI de principales tipos de cambio problemáticos, ya que ayuda a identificar qué servicios reciben cambios con mayor frecuencia y cuáles se asocian con tasas elevadas de rechazo o demoras. Esta información permite a las personas responsables de los servicios mejorar la estabilidad y gestionar la deuda técnica.
Por qué es importante
Vincula los cambios con servicios de negocio específicos y permite identificar cuáles son más inestables o generan más cambios problemáticos.
Dónde obtenerlo
Suele vincularse desde la base de datos de gestión de la configuración (CMDB) y almacenarse en un campo 'Primary CI' o 'Service' del objeto Change Request.
Ejemplos
Servicio de correo electrónico (Exchange)Sistema ERP (SAP)Conmutador de red principal (CISCO-4500X)
|
|||
|
Solicitante del cambio
ChangeSubmitter
|
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, quien se encarga de su implementación más adelante en el proceso. Analizar quién envía las solicitudes de cambio puede ayudar a identificar patrones relacionados con su calidad. Por ejemplo, podría revelar que ciertas personas o equipos envían con frecuencia solicitudes incompletas que se rechazan o requieren retrabajo. Esta información puede servir 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, analizar la calidad de los envíos por persona o equipo e identificar oportunidades de formación.
Dónde obtenerlo
Suele corresponder al campo 'Created By' o 'Requested By' del objeto Change Request.
Ejemplos
Susan MillerDavid ChenMaria Garcia
|
|||
|
Tiempo de ciclo de implementación
ImplementationCycleTime
|
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 que lleva la fase de implementación del cambio. Se calcula como el tiempo transcurrido entre las actividades 'Change Implementation Started' y 'Change Implemented'. Este atributo se utiliza para calcular el KPI «Tiempo promedio de implementación de cambios» y es compatible con el Dashboard «Flujo y retrasos en la implementación de cambios». Ayuda a distinguir los retrasos de planificación de los de ejecución, para que los equipos puedan centrar las mejoras en el trabajo técnico de implementación.
Por qué es importante
Aísla el rendimiento de la fase de implementación propiamente dicha y ayuda a identificar cuellos de botella técnicos o relacionados con los recursos, por separado de los retrasos en las aprobaciones.
Dónde obtenerlo
Se calcula en la herramienta de Process Mining o durante la transformación de datos, obteniendo la diferencia entre las marcas de tiempo de los eventos de inicio y fin de la implementación.
Ejemplos
4 horas y 15 minutos1 día y 2 horas30 minutos
|
|||
|
Unidad de negocio
BusinessUnit
|
Unidad de negocio o departamento que solicitó el cambio o se beneficiará de él. | ||
|
Descripción
Este atributo vincula la solicitud de cambio con una parte específica de la organización, como 'Finanzas', 'Marketing' u 'Operaciones'. Así aporta contexto de negocio a un proceso que, de otro modo, sería puramente técnico. Analizar los datos por unidad de negocio permite ver de dónde surge la demanda de cambios. Puede ayudar a establecer modelos de asignación de costes, entender el impacto de los cambios de TI en distintas funciones del negocio e identificar si algunas unidades tienen cambios más complejos o demorados que otras.
Por qué es importante
Aporta contexto de negocio 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 quien solicita el cambio.
Ejemplos
FinanzasRecursos humanosVentas y marketingOperaciones
|
|||
Actividades de gestión de cambios
| Actividad | Descripción | ||
|---|---|---|---|
|
Cambio aprobado por el CAB
|
Hito clave en el que el Comité Asesor de Cambios (CAB) o la autoridad designada aprueba la ejecución del cambio. Se deduce cuando el estado de la solicitud de cambio se actualiza a «Aprobado». | ||
|
Por qué es importante
Esta actividad marca el final del ciclo de aprobación. Desbloquea el proceso para que puedan comenzar la planificación y la implementación, y es fundamental para el KPI de tiempo del ciclo de aprobación de cambios.
Dónde obtenerlo
Se deduce del historial de auditoría del objeto de solicitud de cambio, concretamente de la marca de tiempo en la que el campo «Status» cambia a «Approved».
Capturar
Se deduce del cambio de estado a «Approved».
Tipo de evento
inferred
|
|||
|
Cambio cerrado
|
Esta actividad marca el 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 hito de éxito, esta actividad es esencial para calcular el tiempo de ciclo integral de los cambios completados correctamente. Confirma que han concluido todos los pasos del proceso.
Dónde obtenerlo
Se infiere de la marca de tiempo del cambio final de estado a 'Closed' en el historial de auditoría del objeto Change Request.
Capturar
Se infiere del cambio final de estado 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 fundamental para el éxito y un dato clave para los KPI de tasa de finalización puntual de cambios y tiempo promedio de implementación de cambios. Marca el fin de la fase de ejecución.
Dónde obtenerlo
Se infiere del registro de auditoría del objeto Change Request, a partir de la marca de tiempo del cambio de estado a 'Implemented' o 'Pending Verification'.
Capturar
Se infiere del cambio de estado a 'Implemented'.
Tipo de evento
inferred
|
|||
|
Cambio programado
|
Esta actividad marca el momento en que se confirman y registran formalmente la fecha y la hora de implementación del cambio. Se registra cuando el estado se actualiza a «Scheduled». | ||
|
Por qué es importante
Este es un hito clave de compromiso. Marca el paso de un concepto aprobado a una acción planificada y es un requisito previo para la implementación.
Dónde obtenerlo
Se infiere del historial del objeto Change Request al registrar la marca de tiempo en que el campo 'Status' cambia a 'Scheduled'.
Capturar
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. Por lo general, se deduce cuando el estado de la solicitud pasa a una fase que indica que está lista para su aprobación, como «En espera de aprobación». | ||
|
Por qué es importante
El seguimiento de esta actividad permite medir la duración de la fase de evaluación y comprobar que el análisis de riesgos se realice sistemáticamente antes de la aprobación. Esto contribuye al KPI de cumplimiento de la evaluación de riesgos.
Dónde obtenerlo
Se deduce del historial del objeto de solicitud de cambio. Se registra la marca de tiempo en la que el campo «Status» cambia de «Assessing» a un estado como «Awaiting CAB Approval».
Capturar
Se deduce 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 de un cambio de estado a 'Post Implementation Review'. | ||
|
Por qué es importante
Hacer seguimiento de esta actividad permite cerrar el ciclo de retroalimentación de los cambios. Es esencial para la mejora continua y contribuye directamente al KPI de tasa de revisiones posteriores a la implementación.
Dónde obtenerlo
Se infiere del historial de auditoría del objeto Change Request, al registrar la marca de tiempo en que 'Status' pasa a un estado como 'Post Implementation Review'.
Capturar
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. Por lo general, se registra cuando se crea un nuevo registro en el objeto de negocio de solicitudes de cambio, 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 las demás permite conocer la duración total del ciclo e identificar retrasos en las primeras etapas.
Dónde obtenerlo
Este evento se obtiene de la marca de tiempo de creación del registro de la solicitud de cambio. En Ivanti Cherwell, suele almacenarse en el campo «CreatedDateTime» del objeto de negocio de solicitudes de cambio.
Capturar
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 se retira una solicitud de cambio aprobada o en curso 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 al registrar la marca de tiempo en que el campo 'Status' del objeto Change Request cambia a 'Cancelled'.
Capturar
Se infiere del cambio de estado a 'Cancelled'.
Tipo de evento
inferred
|
|||
|
Cambio en espera de aprobación
|
Esta actividad representa el periodo durante el cual una solicitud de cambio está pendiente de una decisión formal del Comité Asesor de Cambios (CAB) o de otra autoridad de aprobación. Se deduce de un estado como «Pendiente de aprobación» o «En espera del CAB». | ||
|
Por qué es importante
Esta actividad representa un tiempo de espera crítico. Analizar su duración ayuda a identificar cuellos de botella en el flujo de trabajo de aprobación, una causa 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 de solicitudes de cambio se actualiza a «Pending Approval» o a un valor equivalente.
Capturar
Se identifica cuando se pasa al estado «Pending Approval».
Tipo de evento
inferred
|
|||
|
Cambio rechazado
|
Esta actividad representa la decisión definitiva 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 «Rechazado». | ||
|
Por qué es importante
Este es un punto final crítico del proceso. Analizar los cambios rechazados y sus motivos ayuda a mejorar la calidad de las solicitudes iniciales y contribuye al KPI de tasa de rechazo de solicitudes de cambio.
Dónde obtenerlo
Se deduce de la marca de tiempo del historial de auditoría en la que el campo «Status» del objeto de solicitud de cambio se actualiza a «Rejected».
Capturar
Se deduce del cambio de estado a «Rejected».
Tipo de evento
inferred
|
|||
|
Inicio de la implementación del cambio
|
Representa el inicio de la ejecución técnica del cambio. Por lo general, 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 del periodo de implementación. El tiempo transcurrido entre esta actividad y 'Cambio implementado' corresponde a la duración real de la implementación y es un componente clave del tiempo de ciclo total.
Dónde obtenerlo
Se infiere del historial de auditoría del objeto Change Request. Corresponde a la marca de tiempo en que el campo 'Status' cambia a un valor como 'In Progress' o 'Implementing'.
Capturar
Se infiere del cambio de estado a 'In Progress'.
Tipo de evento
inferred
|
|||
|
Plan de implementación elaborado
|
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 deduce 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 esta etapa pueden afectar al plazo general del cambio, incluso después de su aprobación.
Dónde obtenerlo
Puede deducirse de la marca de tiempo del cambio de estado de «Approved» a «Scheduled». También puede vincularse a la cumplimentación de campos de planificación específicos.
Capturar
Se deduce del cambio de estado de «Approved» a «Scheduled».
Tipo de evento
inferred
|
|||
|
Solicitud de cambio enviada 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 deduce cuando el estado de la solicitud pasa de «Nuevo» o «Borrador» a un estado como «En evaluación». | ||
|
Por qué es importante
Esta actividad marca el inicio del proceso formal de cambio, una vez introducidos los datos iniciales. El tiempo transcurrido entre la creación y el envío puede indicar necesidades de formación o fricciones en el proceso.
Dónde obtenerlo
Se deduce del registro de auditoría o del historial del objeto de solicitud de cambio, identificando la marca de tiempo en la que el campo «Status» cambia a un valor como «Assessing» o «Submitted».
Capturar
Se deduce del cambio de estado de «New» a «Assessing».
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 tuvo 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 permite comprobar que no se omitan los pasos de control de calidad. Es fundamental para prevenir incidentes causados por cambios.
Dónde obtenerlo
Se registra a partir de la marca de tiempo de un cambio de estado en el objeto Change Request, por ejemplo, al pasar a 'Verification' o 'User Acceptance Testing'.
Capturar
Se infiere del cambio de estado a 'Verification'.
Tipo de evento
inferred
|
|||
Guías de extracción
¿Todo listo para empezar?
Utilice este Template para iniciar el análisis de su proceso de gestión de cambios e impulsar mejoras importantes. Empiece hoy mismo a optimizar las actualizaciones y hacerlas más eficientes.
Logre un 95 % de éxito en los cambios: optimice Ivanti Cherwell ahora
Elimine cuellos de botella, reduzca riesgos y alcance un 95 % de éxito en los cambios.
No se requiere tarjeta de crédito. Empiece de inmediato.