Su Template de datos de gestión de cambios
Su Template de datos de gestión de cambios
- Atributos recomendados que debe recopilar
- Actividades clave que debe supervisar para descubrir el proceso con precisión
- Orientación para extraer datos de ServiceNow
Atributos de Change Management
| Nombre | Descripción | ||
|---|---|---|---|
|
Hora del evento
EventTime
|
Marca de tiempo exacta en la que ocurrió una actividad o un evento específicos. | ||
|
Descripción
La hora del evento registra la fecha y hora exactas en que se ejecutó una actividad o se registró un cambio de estado. Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos y para cualquier análisis basado en duraciones. En Process Mining, este atributo permite calcular los tiempos de ciclo, los tiempos de procesamiento y los tiempos de espera entre actividades. Es esencial para los Dashboards que analizan el rendimiento, como Tiempo de ciclo de aprobación del cambio y Flujo del proceso de cambio de principio a fin. Las marcas de tiempo precisas son la base para identificar retrasos y medir la eficiencia del proceso frente a los SLA.
Por qué es importante
Esta marca de tiempo es crucial para secuenciar correctamente los eventos y calcular todas las métricas basadas en el tiempo, incluidos los tiempos de ciclo, las duraciones y el cumplimiento de los SLA.
Dónde obtenerlo
Tabla de ServiceNow: sys_audit, campo: sys_created_on. Proporciona la marca de tiempo de cada cambio registrado.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
ID de Change Request
ChangeRequestNumber
|
Identificador único de una Change Request, que sirve como ID principal del caso para agrupar todos los eventos relacionados. | ||
|
Descripción
El ID de Change Request es la base del análisis del proceso de gestión de cambios. Es un número único asignado a cada Change Request, como «CHG0030001», que vincula todas las actividades, aprobaciones y tareas. En Process Mining, este atributo se utiliza para reconstruir el recorrido integral de cada cambio. Permite a las personas analistas seguir el ciclo de vida completo, desde la creación hasta el cierre, y ofrece una visión coherente de cómo avanza cada cambio por el sistema. Analizar los procesos agrupados por este ID es esencial para calcular los tiempos de ciclo, identificar ciclos de retrabajo y comprender las variantes del proceso.
Por qué es importante
Este ID es esencial para realizar el seguimiento de todo el ciclo de vida de un cambio y permite analizar por completo el flujo del proceso, su duración y el cumplimiento de cada solicitud.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: number
Ejemplos
CHG0030001CHG0030045CHG0030112
|
|||
|
Nombre de la actividad
ActivityName
|
Nombre de un evento o una tarea específicos que tuvieron lugar dentro del proceso de gestión de cambios. | ||
|
Descripción
El nombre de la actividad describe un paso discreto o un cambio de estado en el ciclo de vida de una Change Request. Algunos ejemplos son «Change Awaiting Assessment», «Approval Requested» y «Change Implemented». Estas actividades forman los nodos del mapa de procesos descubierto. Analizar estas actividades permite examinar detalladamente el flujo del proceso. Al realizar un seguimiento de la secuencia y la frecuencia de las actividades, las organizaciones pueden identificar rutas habituales, desviaciones del proceso estándar y cuellos de botella en los que los cambios suelen quedar detenidos. Esto es fundamental para visualizar el proceso y calcular métricas como los tiempos de transición entre pasos.
Por qué es importante
Constituye la estructura central del mapa de procesos, ya que permite visualizar el flujo del proceso, identificar cuellos de botella y analizar desviaciones.
Dónde obtenerlo
Se deriva de los cambios en el campo «state» u otros campos de estado clave de la tabla «change_request», que suelen capturarse en la tabla «sys_audit».
Ejemplos
Change aprobadaImplementación iniciadaChange cerradaChange cancelada
|
|||
|
Elemento de configuración
ConfigurationItem
|
Componente, servicio o sistema de TI específico al que afecta el cambio. | ||
|
Descripción
Configuration Item (CI) es el activo de la base de datos de gestión de la configuración (CMDB) al que afectará el cambio. Puede ser un servidor, una aplicación de software, un dispositivo de red o un servicio empresarial. Este atributo proporciona un contexto esencial para el cambio. En Process Mining, permite segmentar el análisis por tipo de activo modificado. Por ejemplo, el panel «Change Testing Duration Analysis» utiliza este atributo para comparar los tiempos de prueba de distintas aplicaciones o sistemas y ayudar a identificar los CI asociados con ciclos de prueba más largos.
Por qué es importante
Proporciona un contexto empresarial esencial y permite filtrar el análisis por la aplicación, el servicio o el sistema afectado para identificar problemas específicos de cada componente.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: cmdb_ci
Ejemplos
SAP ERPOracle Database 19cServicio de correo electrónicoWebServer-01
|
|||
|
Estado del cambio
ChangeState
|
Estado actual o histórico de la Change Request, como «Assess», «Authorize», «Implement» o «Closed». | ||
|
Descripción
El atributo Change State representa el estado de una Change Request en un momento determinado. Ofrece un resumen general de la fase del ciclo de vida en la que se encuentra el cambio. A diferencia de Activity, que representa un evento específico, State es la condición resultante de ese evento. En el análisis, Change State se utiliza para categorizar casos y comprender sus resultados. Es fundamental para filtrar cambios, por ejemplo, para analizar únicamente los cambios «Closed» o investigar por qué muchos cambios están atascados en el estado «Authorize». También respalda directamente KPI como Change Failure Rate cuando existe un estado «Failed».
Por qué es importante
Proporciona una instantánea del estado de la Change Request, lo que permite analizar resultados, filtrar casos e identificar cambios estancados.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: state
Ejemplos
EvaluarAutorizarProgramadoImplementarRevisarCerradoCancelado
|
|||
|
Grupo de asignación
AssignmentGroup
|
Equipo o grupo responsable de la Change Request. | ||
|
Descripción
El grupo de asignación indica qué equipo es actualmente responsable de la solicitud de cambio, por ejemplo, 'Aprobación del CAB', 'Ingeniería de redes' o 'Administradores de bases de datos'. Esta dimensión es fundamental para analizar el rendimiento del proceso en distintas áreas funcionales. Este atributo se utiliza para medir la eficiencia a nivel de equipo, identificar cuellos de botella dentro de grupos concretos y analizar la eficacia de las transferencias entre equipos. Dashboards como 'Eficiencia de las transferencias interfuncionales' y 'Rendimiento de la implementación de cambios' dependen en gran medida de estos datos para localizar los retrasos causados por dependencias entre equipos.
Por qué es importante
Permite analizar el rendimiento por equipo, destacar cuellos de botella específicos de cada grupo y medir la eficiencia de las transferencias entre distintas áreas funcionales.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: assignment_group
Ejemplos
Aprobación del CABEquipo de redesSoporte de servidoresAdministradores de bases de datos
|
|||
|
Hora de finalización
EndTime
|
Marca de tiempo en la que concluyó una actividad. A menudo se obtiene de la hora de inicio de la actividad siguiente. | ||
|
Descripción
End Time marca la finalización de una actividad. Aunque los sistemas de origen suelen registrar el inicio de un evento, la hora de finalización se infiere con frecuencia. Normalmente se calcula como la marca de tiempo de la actividad siguiente en la secuencia del mismo caso. Este atributo es esencial para calcular la duración de cada actividad, conocida como tiempo de procesamiento. Comprender cuánto dura cada paso es fundamental para identificar cuellos de botella e ineficiencias en el proceso. En la actividad final de un caso, End Time coincide con Start Time.
Por qué es importante
Permite calcular el tiempo de procesamiento de las actividades, algo crucial para identificar cuellos de botella y medir la duración de pasos específicos del proceso.
Dónde obtenerlo
Normalmente, este atributo se calcula durante la transformación de datos tomando el StartTime del evento siguiente para el mismo CaseId.
Ejemplos
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Nivel de riesgo
RiskLevel
|
Nivel de riesgo evaluado del cambio, como «High», «Moderate» o «Low». | ||
|
Descripción
Risk Level es el resultado del proceso de evaluación de riesgos de una Change Request. Cuantifica el potencial de consecuencias adversas si se implementa el cambio y ayuda a determinar el nivel de revisión y aprobación necesario. Este atributo es clave para el panel «Risk Assessment Standardization», donde se utiliza para comprobar si los cambios similares reciben calificaciones de riesgo coherentes. Analizar los flujos del proceso por nivel de riesgo también puede revelar si los cambios de alto riesgo siguen correctamente una ruta de aprobación y pruebas más rigurosa que los cambios de bajo riesgo, lo que constituye una comprobación importante de cumplimiento.
Por qué es importante
Es esencial para el análisis de cumplimiento y para garantizar que los cambios de alto riesgo reciban el nivel de revisión adecuado y sigan un proceso más riguroso.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: risk
Ejemplos
AltoModeradoBajo
|
|||
|
Prioridad
Priority
|
Nivel de prioridad de la Change Request, determinado por su impacto y urgencia. | ||
|
Descripción
Priority indica la importancia de una Change Request y determina el orden en que debe atenderse. A menudo se deriva del impacto y la urgencia del cambio, con valores como «Critical», «High», «Moderate» y «Low». Analizar por prioridad es esencial para garantizar que los cambios de alta prioridad se procesen más rápido que los de baja prioridad. Respaldar el panel «Critical Change Performance» permite a las personas analistas realizar un seguimiento de los tiempos de ciclo y las tasas de fallo específicamente de los cambios más importantes. Cualquier desviación en la que los cambios de baja prioridad se completen más rápido que los de alta prioridad indica un problema de asignación de recursos o de ejecución del proceso.
Por qué es importante
Es crucial para evaluar si los recursos se asignan correctamente a los cambios más críticos y supervisar su rendimiento por separado.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: priority
Ejemplos
1 - Crítico2 - Alto3 - Moderado4 - Bajo
|
|||
|
Tipo de cambio
ChangeType
|
Clasificación del cambio, como «Standard», «Normal» o «Emergency». | ||
|
Descripción
El tipo de cambio clasifica la solicitud de cambio según su naturaleza, riesgo y requisitos de aprobación. Los cambios estándar se aprueban previamente, los cambios normales siguen el proceso completo y los cambios de emergencia utilizan una ruta acelerada. Esta es una dimensión fundamental para el análisis del proceso, ya que los distintos tipos de cambio tienen modelos de proceso diferenciados y legítimos. Comparar el rendimiento de los cambios normales y de emergencia puede revelar conclusiones importantes sobre el cumplimiento del proceso y la eficiencia. También se utiliza en Dashboards como 'Estandarización de la evaluación de riesgos' para garantizar que los cambios similares reciban un tratamiento coherente.
Por qué es importante
Permite segmentar el análisis, ya que los distintos tipos de cambio siguen flujos de proceso autorizados diferentes y tienen expectativas de rendimiento propias.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: type
Ejemplos
EstándarNormalEmergencia
|
|||
|
Código de cierre
CloseCode
|
Código que indica el resultado cuando se cerró la solicitud de cambio, como «Correcto» o «Incorrecto». | ||
|
Descripción
El código de cierre proporciona la disposición final de una solicitud de cambio completada. Registra formalmente si el cambio se implementó correctamente, con incidencias o si se revirtió. Este atributo es una entrada directa para el KPI «Tasa de fallos de cambios». Al analizar la distribución de los códigos de cierre, las organizaciones pueden cuantificar el éxito de sus iniciativas de cambio. Filtrar el mapa de procesos para mostrar los cambios con un código de cierre «Incorrecto» es una técnica eficaz para el análisis de causas raíz, ya que revela patrones de proceso comunes que conducen al fallo.
Por qué es importante
Mide directamente el resultado de un cambio y proporciona los datos principales necesarios para calcular la tasa de fallos de cambios y analizar las causas raíz de los cambios fallidos.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: close_code
Ejemplos
CorrectoCorrecto con incidenciasIncorrecto / Revertido
|
|||
|
Es retrabajo
IsRework
|
Indicador booleano que es verdadero si una actividad representa la repetición de un paso anterior dentro del mismo caso. | ||
|
Descripción
Este atributo calculado identifica las actividades que constituyen retrabajo. El retrabajo ocurre cuando el proceso debe volver a un paso ya completado, por ejemplo, cuando se rechaza un cambio después de su aprobación y se devuelve para una nueva evaluación. Este indicador es fundamental para cuantificar la ineficiencia del proceso. Es compatible directamente con el KPI «Tasa de retrabajo de cambios» y con el Dashboard «Análisis de fallos y retrabajo de cambios». Al filtrar las actividades en las que «Es retrabajo» es verdadero, los analistas pueden aislar y estudiar las causas del retrabajo, como evaluaciones iniciales incompletas o cambios en los requisitos, y tomar medidas para reducir el desperdicio.
Por qué es importante
Cuantifica directamente la ineficiencia del proceso al señalar el trabajo repetido, lo que ayuda a identificar y abordar las causas raíz de los ciclos del proceso y del esfuerzo desperdiciado.
Dónde obtenerlo
Se calcula durante la transformación de datos detectando si la misma actividad, o una anterior en el flujo estándar, ya se produjo para el CaseId indicado.
Ejemplos
truefalse
|
|||
|
Estado del SLA
SlaState
|
Estado de la solicitud de cambio en relación con su Acuerdo de Nivel de Servicio (SLA), como «En plazo», «En riesgo» o «Incumplido». | ||
|
Descripción
El estado del SLA indica si la solicitud de cambio avanza dentro de los plazos definidos por su SLA. Este estado puede supervisarse en cada etapa del proceso. Este atributo es esencial para supervisar el cumplimiento de los compromisos de nivel de servicio. Es la fuente de datos principal del Dashboard «Resumen del rendimiento del SLA de cambios» y del KPI «Tasa de cumplimiento del SLA de cambios». Analizar dónde y por qué se incumplen los SLA permite a la organización abordar los retrasos sistémicos y mejorar la previsibilidad de la prestación del servicio.
Por qué es importante
Proporciona una medida directa del rendimiento frente a los plazos y permite supervisar y analizar de forma proactiva los incumplimientos de los SLA para mejorar la prestación del servicio.
Dónde obtenerlo
Puede obtenerse de la tabla «task_sla» de ServiceNow, que registra los SLA relacionados con tareas como las solicitudes de cambio, o calcularse a partir de los campos de fecha límite.
Ejemplos
En cursoEn riesgoIncumplido
|
|||
|
Impacto
Impact
|
Efecto potencial del cambio en las operaciones empresariales, valorado en una escala como High, Medium o Low. | ||
|
Descripción
Impact mide el efecto potencial en la empresa si la Change Request no se gestiona correctamente. Es un dato clave, junto con Urgency, para determinar la Priority general del cambio. Analizar por Impact ayuda a garantizar que los cambios que afectan a servicios críticos se gestionen con el cuidado adecuado. Se utiliza en el panel «Critical Change Performance» para aislar y supervisar los cambios con un impacto empresarial alto. También permite verificar la coherencia de la evaluación de riesgos y garantizar que los cambios de alto impacto no reciban un nivel de riesgo bajo sin justificación.
Por qué es importante
Ayuda a priorizar los cambios según su posible efecto empresarial y se utiliza para validar que los cambios de alto impacto se gestionen con la diligencia adecuada.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: impact
Ejemplos
1 - Alto2 - Medio3 - Bajo
|
|||
|
Sistema de origen
SourceSystem
|
Sistema del que se extrajeron los datos, normalmente «ServiceNow». | ||
|
Descripción
Este atributo identifica el origen de los datos del proceso. Aunque en este caso se espera que sea ServiceNow, es un campo crucial para la gobernanza de datos y para situaciones en las que se combinan datos de varios sistemas. En el análisis, garantiza la trazabilidad clara de los datos y ayuda a validar su origen. En organizaciones con varias herramientas ITSM o sistemas integrados, este atributo permite filtrar y comparar procesos en distintas plataformas.
Por qué es importante
Proporciona una trazabilidad clara de los datos y garantiza que el origen de los datos del proceso quede documentado, algo fundamental para la gobernanza de datos y el análisis de varios sistemas.
Dónde obtenerlo
Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos (ETL).
Ejemplos
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Tiempo de ciclo
CycleTime
|
Tiempo total transcurrido desde la creación hasta el cierre de una solicitud de cambio. | ||
|
Descripción
El tiempo de ciclo es una métrica a nivel de caso que mide la duración total del ciclo de vida de una solicitud de cambio. Se calcula como la diferencia entre la marca de tiempo del primer evento y la del último evento de una solicitud de cambio determinada. Es un KPI fundamental para medir la velocidad general del proceso. Se utiliza en el Dashboard «Flujo del proceso de cambio de extremo a extremo» para ofrecer una visión general del rendimiento del proceso. Analizar las tendencias del tiempo de ciclo y compararlas en distintas dimensiones, como el tipo de cambio o la prioridad, ayuda a las organizaciones a identificar oportunidades de mejora estratégica del proceso.
Por qué es importante
Mide la duración de extremo a extremo del proceso de cambio y proporciona un indicador clave de la velocidad y la eficiencia generales del proceso.
Dónde obtenerlo
Se calcula a nivel de caso durante el análisis de datos, restando el StartTime mínimo del StartTime máximo para cada CaseId.
Ejemplos
60480012096002592000
|
|||
|
Última actualización de datos
LastDataUpdate
|
Marca de tiempo que indica cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen. | ||
|
Descripción
Este atributo proporciona la marca de tiempo de la última extracción de datos. Es un campo de metadatos fundamental para comprender la actualidad de los datos analizados. Las personas analistas utilizan esta marca de tiempo para confirmar que trabajan con información actualizada y conocer la antigüedad de los datos. Es especialmente importante para los Dashboards operativos que supervisan el rendimiento del proceso en curso, ya que garantiza que las decisiones no se basen en datos obsoletos.
Por qué es importante
Indica la actualidad de los datos y garantiza que los análisis y Dashboards se basen en información actual y relevante.
Dónde obtenerlo
Es un campo de metadatos generado durante el proceso de extracción y transformación de datos (ETL) que indica el momento en que se obtuvieron los datos.
Ejemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Urgencia
Urgency
|
Velocidad con la que debe resolverse un cambio, valorada en una escala como High, Medium o Low. | ||
|
Descripción
La urgencia determina con qué rapidez debe implementarse un cambio. Refleja la sensibilidad temporal de la solicitud desde una perspectiva empresarial. Junto con el impacto, se utiliza para calcular la prioridad general. Aunque la prioridad es el campo principal para el análisis, la urgencia aporta contexto adicional. Puede utilizarse para investigar por qué ciertos cambios se marcan como urgentes y si el proceso los gestiona eficazmente sin comprometer la estabilidad. Ayuda a responder preguntas sobre si la organización opera con demasiada frecuencia en un modo reactivo y de alta urgencia.
Por qué es importante
Aporta contexto sobre la sensibilidad temporal de un cambio y ayuda a analizar si el proceso gestiona eficazmente las solicitudes críticas por tiempo.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: urgency
Ejemplos
1 - Alto2 - Medio3 - Bajo
|
|||
|
Usuario asignado
AssignedToUser
|
Persona responsable de la Change Request en un momento determinado. | ||
|
Descripción
Este atributo identifica a la persona concreta asignada para trabajar en la Change Request. Puede cambiar varias veces durante el ciclo de vida, a medida que la solicitud pasa entre distintas fases y equipos. Analizar por usuario ayuda a comprender la distribución de la carga de trabajo y el rendimiento individual, así como a identificar necesidades de capacitación. También es clave para analizar las transferencias, especialmente al combinarlo con Assignment Group, para comprobar con qué eficiencia se transfiere el trabajo entre personas.
Por qué es importante
Ayuda a realizar el seguimiento de la carga de trabajo y el rendimiento de cada usuario, y es crucial para analizar los retrasos en las transferencias entre distintos recursos.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: assigned_to
Ejemplos
Beth AnglinDavid LooAbel Tuter
|
|||
Actividades de Change Management
| Actividad | Descripción | ||
|---|---|---|---|
|
Change aprobada
|
La Change Request ha recibido todas las autorizaciones necesarias para avanzar a las fases de programación e implementación. Es un hito crítico que se captura cuando se concede la aprobación final y el campo «approval» se establece en «approved». | ||
|
Por qué es importante
Este hito concluye la fase de aprobación. Es esencial para medir los tiempos del ciclo de aprobación e identificar cuellos de botella en el proceso de toma de decisiones.
Dónde obtenerlo
Se infiere a partir del cambio del campo «approval» de la tabla change_request a «approved». La marca de tiempo procede del historial de auditoría de este cambio.
Recopilar
Capture la marca de tiempo cuando el campo «approval» pase a «approved».
Tipo de evento
inferred
|
|||
|
Change cancelada
|
La Change Request se ha retirado o cancelado en algún momento antes de completar la implementación. Es un estado final alternativo que se captura cuando el estado se establece en «Canceled». | ||
|
Por qué es importante
Analizar los cambios cancelados puede revelar ineficiencias del proceso, como solicitudes creadas innecesariamente o atascadas demasiado tiempo en la aprobación hasta quedar obsoletas.
Dónde obtenerlo
Se infiere a partir del campo «state» de la tabla change_request cuando se establece en «Canceled». La marca de tiempo se obtiene del registro de auditoría de este cambio de estado.
Recopilar
Capture la marca de tiempo cuando el campo «state» se actualice a «Canceled».
Tipo de evento
inferred
|
|||
|
Change cerrada
|
La Change Request se ha completado y revisado correctamente, y ahora se considera finalizada. Es el principal punto final de éxito del proceso y se captura cuando el estado del cambio pasa a «Closed». | ||
|
Por qué es importante
Esta actividad marca la finalización exitosa del ciclo de vida del cambio. Es el evento final para medir la duración integral del proceso y el cumplimiento del SLA.
Dónde obtenerlo
Se infiere a partir del campo «state» de la tabla change_request cuando se establece en «Closed». La marca de tiempo se obtiene del historial de auditoría de este cambio de estado final.
Recopilar
Capture la marca de tiempo cuando el campo «state» se actualice a «Closed».
Tipo de evento
inferred
|
|||
|
Change implementada
|
El trabajo de implementación ha finalizado y el cambio está listo para su revisión, verificación o prueba. Esta actividad se infiere cuando el estado de la Change Request cambia de «Implement» a «Review». | ||
|
Por qué es importante
Este es un hito crítico que concluye la fase de implementación. Es un evento clave para calcular los KPI «Change Failure Rate» y «Change Rework Rate».
Dónde obtenerlo
Se infiere a partir de una transición de estado desde «Implement» a un estado posterior, como «Review». La marca de tiempo se obtiene del historial de auditoría del campo «state» de la tabla change_request.
Recopilar
Identifique cuándo el campo «state» cambia de «Implement» a «Review».
Tipo de evento
inferred
|
|||
|
Change programada
|
Al cambio aprobado se le han asignado una fecha de inicio y una fecha de finalización planificadas, y ahora figura oficialmente en el calendario de implementación. Se infiere cuando el estado de la Change Request cambia a «Scheduled». | ||
|
Por qué es importante
Esta actividad separa las fases de planificación y aprobación de la fase de implementación activa. El tiempo transcurrido en este estado puede indicar retrasos entre la aprobación y el inicio del trabajo.
Dónde obtenerlo
Se infiere a partir de un cambio del campo «state» de la tabla change_request a «Scheduled». La marca de tiempo se obtiene de la entrada correspondiente del registro de auditoría.
Recopilar
Realice el seguimiento de los cambios del campo state a «Scheduled» en el historial de auditoría de la tabla change_request.
Tipo de evento
inferred
|
|||
|
Change Request creada
|
Esta actividad marca la creación de un nuevo registro de Change Request en el sistema. Es el inicio oficial del proceso de gestión de cambios y se captura cuando se inserta una nueva entrada en la tabla change_request. | ||
|
Por qué es importante
Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta otras permite conocer el plazo total e identificar retrasos desde el comienzo del proceso.
Dónde obtenerlo
Este evento corresponde a la marca de tiempo de creación del registro (sys_created_on) en la tabla change_request de ServiceNow.
Recopilar
Utilice la marca de tiempo sys_created_on de la tabla change_request.
Tipo de evento
explicit
|
|||
|
Riesgo e impacto evaluados
|
Representa la finalización del análisis de riesgos e impacto de la Change Request. Es un hito crucial antes de solicitar la aprobación y suele inferirse cuando el cambio sale del estado «Assess» y pasa a «Authorize» o «Awaiting Approval». | ||
|
Por qué es importante
Realizar un seguimiento de la duración de la fase de evaluación es clave para el KPI «Avg. Risk Assessment Cycle Time». Ayuda a estandarizar el proceso de evaluación e identificar dónde los análisis están tardando demasiado.
Dónde obtenerlo
Se infiere a partir de la transición del campo «state» de la tabla change_request de «Assess» a «Authorize». La marca de tiempo del evento se obtiene del registro de auditoría de este cambio de estado.
Recopilar
Identifique cuándo el campo «state» cambia de «Assess» a un estado posterior, como «Authorize».
Tipo de evento
inferred
|
|||
|
Aprobación solicitada
|
Esta actividad indica que la Change Request se ha enviado formalmente para su aprobación, normalmente a una persona responsable o a un Change Advisory Board (CAB). El evento se captura cuando el estado de aprobación de la Change Request se establece en «requested». | ||
|
Por qué es importante
Esto marca el inicio del ciclo de aprobación. Medir el tiempo desde este evento hasta «Change Approved» permite calcular directamente el KPI «Average Change Approval Time».
Dónde obtenerlo
Se infiere a partir del cambio del campo «approval» de la tabla change_request a «requested». La marca de tiempo se registra en la tabla sys_audit para este campo.
Recopilar
Marca de tiempo del momento en que el campo «approval» de la tabla change_request se establece en «requested».
Tipo de evento
inferred
|
|||
|
Change en espera de evaluación
|
La Change Request se ha enviado y ahora espera una evaluación técnica y empresarial. Normalmente se infiere cuando el estado de la Change Request cambia a «Assess» o a un estado similar, lo que indica que ha dejado la fase de borrador. | ||
|
Por qué es importante
Esta actividad ayuda a medir el tiempo de la transferencia inicial desde la persona solicitante hasta el equipo de evaluación. Los retrasos en esta etapa pueden indicar problemas con la calidad inicial de los datos o con la disponibilidad de recursos para la evaluación.
Dónde obtenerlo
Se infiere a partir de un cambio en el campo «state» de la tabla change_request, normalmente a un valor como «Assess». La marca de tiempo se obtiene del historial de auditoría (sys_audit) de este cambio de campo.
Recopilar
Realice el seguimiento de los cambios del campo state a «Assess» en el historial de auditoría de la tabla change_request.
Tipo de evento
inferred
|
|||
|
Change reabierta
|
La Change Request ha regresado a un estado anterior, como «Implement» o «Assess», después de alcanzar una fase posterior. Este evento se infiere a partir de una transición de estado no lineal e indica que se ha realizado un retrabajo. | ||
|
Por qué es importante
Esta actividad es crucial para identificar ciclos de retrabajo y calcular el KPI «Change Rework Rate». Las reaperturas frecuentes indican problemas de calidad en la implementación, las pruebas o la planificación.
Dónde obtenerlo
Se infiere mediante el análisis de la secuencia de cambios de estado en el historial de auditoría de change_request. Una transición de un estado posterior, por ejemplo «Review», a uno anterior, por ejemplo «Implement», indica una reapertura.
Recopilar
Detecte una transición hacia atrás y no secuencial en el historial del campo «state».
Tipo de evento
inferred
|
|||
|
Change rechazada
|
La Change Request ha sido rechazada por una persona aprobadora o por el CAB. Esta actividad representa un estado terminal para la solicitud, salvo que se modifique y se vuelva a enviar. Se captura cuando el campo «approval» se establece en «rejected». | ||
|
Por qué es importante
El seguimiento de los rechazos ayuda a identificar motivos habituales de denegación, como información incompleta o un riesgo elevado. Este análisis puede mejorar la calidad de futuras solicitudes de cambio.
Dónde obtenerlo
Se infiere a partir del cambio del campo «approval» de la tabla change_request a «rejected». La marca de tiempo se obtiene del historial de auditoría.
Recopilar
Capture la marca de tiempo cuando el campo «approval» pase a «rejected».
Tipo de evento
inferred
|
|||
|
Implementación iniciada
|
El trabajo de implementación del cambio ha comenzado. Se captura cuando el estado de la Change Request se actualiza a «Implement», lo que indica la transición de la planificación a la ejecución. | ||
|
Por qué es importante
Esto marca el inicio del trabajo práctico de implementación. Es el punto de partida para medir el KPI «Average Implementation Duration» y analizar la eficiencia del equipo.
Dónde obtenerlo
Se infiere a partir del cambio del campo «state» de la tabla change_request a «Implement». La marca de tiempo se obtiene del registro de auditoría de esta transición de estado.
Recopilar
Capture la marca de tiempo del cambio de estado a «Implement» en el historial de auditoría de change_request.
Tipo de evento
inferred
|
|||
|
Revisión en curso
|
Se está realizando una revisión posterior a la implementación (PIR) para determinar si el cambio tuvo éxito y cumplió sus objetivos. Se captura cuando el estado de la Change Request se establece en «Review». | ||
|
Por qué es importante
Analizar la duración de la fase de revisión ayuda a identificar retrasos en la validación del éxito del cambio. También permite detectar cambios que incumplen el proceso porque esta etapa se omitió.
Dónde obtenerlo
Se infiere a partir del cambio del campo «state» de la tabla change_request a «Review». La marca de tiempo procede del registro de auditoría de este cambio de estado.
Recopilar
Capture la marca de tiempo del cambio de estado a «Review» en el historial de auditoría de change_request.
Tipo de evento
inferred
|
|||
Guías de extracción
¿Listo para comenzar?
Utilice este Template para preparar sus datos y descubrir información sobre su proceso de gestión de cambios en ServiceNow. Comience hoy mismo a optimizarlo para alcanzar la máxima eficiencia.
¡Detenga los cambios fallidos y mejore ahora sus resultados en ServiceNow!
Localice los cuellos de botella para alcanzar fácilmente una tasa de éxito de cambios del 95 %.
No necesita tarjeta de crédito; la configuración solo tarda unos minutos.