Su Template de datos de gestión de cambios
Su Template de datos de gestión de cambios
- Atributos recomendados para recopilar
- Actividades clave para registrar y descubrir el proceso con precisión
- Indicaciones para extraer datos de ServiceNow
Atributos de gestión de cambios
| Nombre | Descripción | ||
|---|---|---|---|
|
Hora del evento
EventTime
|
Marca de tiempo exacta en que ocurrió una actividad o un evento específicos. | ||
|
Descripción
La hora del evento registra la fecha y hora exactas en que se realizó una actividad o se registró un cambio de estado. Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos y para todos los análisis basados en la duración. 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 'Change Approval Cycle Time' y 'End-to-End Change Process Flow'. Las marcas de tiempo precisas son la base para identificar demoras y medir la eficiencia del proceso con respecto a los SLA.
Por qué es importante
Esta marca de tiempo es fundamental para ordenar correctamente los eventos y calcular todas las métricas temporales, 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 solicitud de cambio
ChangeRequestNumber
|
Identificador único de una solicitud de cambio, que sirve como ID principal del caso para agrupar todos los eventos relacionados. | ||
|
Descripción
El ID de solicitud de cambio es la base del análisis del proceso de gestión de cambios. Es un número único asignado a cada solicitud, como 'CHG0030001', que vincula todas las actividades, aprobaciones y tareas relacionadas. En Process Mining, este atributo se utiliza para reconstruir el recorrido integral de cada cambio. Permite a quienes analizan los datos seguir todo el ciclo de vida, desde la creación hasta el cierre, y obtener una visión coherente de cómo avanza cada cambio por el sistema. Agrupar los procesos 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 seguir 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 durante el proceso de gestión de cambios. | ||
|
Descripción
El nombre de la actividad describe un paso concreto o un cambio de estado en el ciclo de vida de una solicitud de cambio. Algunos ejemplos son 'Cambio pendiente de evaluación', 'Aprobación solicitada' y 'Cambio implementado'. Estas actividades forman los nodos del mapa de procesos descubierto. Analizarlas permite examinar en detalle el flujo del proceso. Al hacer un seguimiento de su secuencia y frecuencia, las organizaciones pueden identificar las rutas habituales, las desviaciones respecto del proceso estándar y los cuellos de botella donde 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
Es la base del mapa de procesos y permite visualizar el flujo del proceso, identificar cuellos de botella y analizar desviaciones.
Dónde obtenerlo
Se obtiene de los cambios en el campo 'state' u otros campos de estado clave de la tabla 'change_request', que suelen registrarse en la tabla 'sys_audit'.
Ejemplos
Cambio aprobadoImplementación iniciadaCambio cerradoCambio cancelado
|
|||
|
Elemento de configuración
ConfigurationItem
|
Componente, servicio o sistema de TI específico al que afecta el cambio. | ||
|
Descripción
El elemento de configuración (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 aporta contexto fundamental sobre el cambio. En Process Mining, permite segmentar el análisis según el tipo de activo que se modifica. Por ejemplo, el Dashboard 'Change Testing Duration Analysis' utiliza este atributo para comparar los tiempos de prueba de distintas aplicaciones o sistemas e identificar qué CI se asocian con ciclos de prueba más largos.
Por qué es importante
Aporta 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 solicitud de cambio, como 'Assess', 'Authorize', 'Implement' o 'Closed'. | ||
|
Descripción
El atributo de estado del cambio representa la situación de una solicitud de cambio en un momento determinado. Ofrece un resumen general de la etapa del ciclo de vida en que se encuentra el cambio. A diferencia de la actividad, que representa un evento específico, el estado refleja la situación resultante de ese evento. En el análisis, el estado del cambio se utiliza para clasificar los casos y comprender sus resultados. Es fundamental para filtrar cambios, por ejemplo, para analizar solo los que están 'Closed' o investigar por qué muchos permanecen detenidos en el estado 'Authorize'. También contribuye directamente a KPI como 'Change Failure Rate' cuando existe un estado 'Failed'.
Por qué es importante
Ofrece una instantánea del estado de la solicitud de cambio y permite analizar los resultados, filtrar casos e identificar cambios detenidos.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: state
Ejemplos
EvaluaciónAutorizaciónProgramadoImplementaciónRevisiónCerradoCancelado
|
|||
|
Grupo de asignación
AssignmentGroup
|
Equipo o grupo responsable de la solicitud de cambio. | ||
|
Descripción
El grupo de asignación indica qué equipo es responsable actualmente de la solicitud de cambio, por ejemplo, 'Aprobación del CAB', 'Ingeniería de redes' o 'Administración de bases de datos'. Es una dimensión fundamental para analizar el rendimiento del proceso en distintas áreas funcionales. Este atributo se utiliza para medir la eficiencia de cada equipo, identificar cuellos de botella en grupos específicos y analizar la eficacia de las transferencias entre equipos. Dashboards como 'Cross-Functional Handoff Efficiency' y 'Change Implementation Throughput' dependen en gran medida de estos datos para identificar demoras causadas por dependencias entre equipos.
Por qué es importante
Permite analizar el rendimiento por equipo, detectar 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 servidoresAdministración de bases de datos
|
|||
|
Hora de fin
EndTime
|
Marca de tiempo en que concluyó una actividad. A menudo se obtiene de la hora de inicio de la actividad siguiente. | ||
|
Descripción
La hora de fin marca la conclusión de una actividad. Aunque los sistemas de origen suelen registrar el inicio de un evento, la hora de fin se infiere con frecuencia. Por lo general, se calcula a partir de la marca de tiempo de la actividad siguiente del mismo caso. Este atributo es esencial para calcular la duración de cada actividad, conocida como tiempo de procesamiento. Saber cuánto tarda cada paso es fundamental para identificar cuellos de botella e ineficiencias en el proceso. En la actividad final de un caso, la hora de fin coincide con la hora de inicio.
Por qué es importante
Permite calcular el tiempo de procesamiento de las actividades, algo fundamental para identificar cuellos de botella y medir la duración de pasos específicos del proceso.
Dónde obtenerlo
Este atributo suele calcularse durante la transformación de datos, tomando el StartTime del siguiente evento del 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 'Alto', 'Moderado' o 'Bajo'. | ||
|
Descripción
El nivel de riesgo es el resultado de la evaluación de riesgos de una solicitud de cambio. Cuantifica la posibilidad de que se produzcan 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 Dashboard 'Risk Assessment Standardization', donde se utiliza para comprobar si los cambios similares reciben una clasificación de riesgo coherente. Analizar los flujos del proceso por nivel de riesgo también permite comprobar si los cambios de alto riesgo siguen correctamente una ruta de aprobación y pruebas más rigurosa que los de bajo riesgo. Esta es una comprobación de cumplimiento clave.
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 solicitud de cambio, determinado por su impacto y urgencia. | ||
|
Descripción
La prioridad indica la importancia de una solicitud de cambio y determina el orden en que debe atenderse. Suele calcularse a partir del impacto y la urgencia del cambio, con valores como 'Crítico', 'Alto', 'Moderado' y 'Bajo'. Analizar los datos por prioridad es esencial para garantizar que los cambios de alta prioridad se procesen más rápido que los de baja prioridad. Esto permite analizar el Dashboard 'Critical Change Performance' y hacer un seguimiento de los tiempos de ciclo y las tasas de fallos de los cambios más importantes. Si los cambios de baja prioridad se completan más rápido que los de alta prioridad, puede haber un problema en la asignación de recursos o en la ejecución del proceso.
Por qué es importante
Es fundamental 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 'Estándar', 'Normal' o 'De emergencia'. | ||
|
Descripción
El tipo de cambio clasifica la solicitud según su naturaleza, nivel de riesgo y requisitos de aprobación. Los cambios estándar están preaprobados, los normales siguen el proceso completo y los de emergencia utilizan una ruta acelerada. Es una dimensión fundamental para el análisis del proceso, ya que cada tipo de cambio tiene un modelo de proceso distinto y válido. Comparar el rendimiento de los cambios normales con el de los cambios de emergencia puede aportar información importante sobre el cumplimiento del proceso y su eficiencia. También se utiliza en Dashboards como 'Risk Assessment Standardization' para garantizar que los cambios similares reciban un tratamiento coherente.
Por qué es importante
Permite segmentar el análisis, ya que cada tipo de cambio sigue flujos de proceso autorizados distintos y tiene expectativas de rendimiento propias.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: type
Ejemplos
EstándarNormalDe emergencia
|
|||
|
Código de cierre
CloseCode
|
Código que indica el resultado al cerrar una solicitud de cambio, por ejemplo, «Correcto» o «Incorrecto». | ||
|
Descripción
El código de cierre indica el resultado final de una solicitud de cambio completada. Registra formalmente si el cambio se implementó correctamente, si hubo problemas o si se revirtió. Este atributo es un dato de entrada directo para el KPI «Tasa de cambios fallidos». 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 el código de cierre «Incorrecto» es una técnica eficaz de análisis de causas raíz, ya que revela patrones comunes del proceso que provocan fallos.
Por qué es importante
Mide directamente el resultado de un cambio y proporciona los datos principales para calcular la tasa de cambios fallidos y analizar sus causas raíz.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: close_code
Ejemplos
CorrectoCorrecto, con problemasIncorrecto / Revertido
|
|||
|
Es retrabajo
IsRework
|
Indicador booleano que es verdadero si una actividad repite un paso anterior del mismo caso. | ||
|
Descripción
Este atributo calculado identifica las actividades que constituyen retrabajo. Hay retrabajo cuando el proceso debe volver a un paso ya completado, por ejemplo, si 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. Contribuye directamente al KPI «Tasa de retrabajo en cambios» y al Dashboard «Análisis de fallos y retrabajo en cambios». Al filtrar las actividades en las que «Es retrabajo» es verdadero, los analistas pueden aislar y estudiar las causas, 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 repetitivos y el esfuerzo desperdiciado.
Dónde obtenerlo
Se calcula durante la transformación de datos, detectando si la misma actividad (o una anterior del flujo estándar) ya se ha producido para el CaseId correspondiente.
Ejemplos
truefalse
|
|||
|
Estado del SLA
SlaState
|
Estado de la solicitud de cambio respecto a su acuerdo de nivel de servicio (SLA), por ejemplo, «En curso», «En riesgo» o «Incumplido». | ||
|
Descripción
El estado del SLA indica si la solicitud de cambio avanza dentro de los plazos definidos en el SLA. Este estado puede seguirse en cada etapa del proceso. Este atributo es esencial para supervisar el cumplimiento de los compromisos de nivel de servicio. Es la fuente principal de datos para el Dashboard «Resumen del rendimiento del SLA de cambios» y el KPI «Tasa de cumplimiento del SLA de cambios». Analizar dónde y por qué se incumplen los SLA permite a la organización abordar retrasos sistémicos y mejorar la previsibilidad de la prestación de servicios.
Por qué es importante
Mide directamente el rendimiento respecto a los plazos y permite supervisar y analizar de forma proactiva los incumplimientos del SLA para mejorar la prestación de servicios.
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 de vencimiento.
Ejemplos
En cursoEn riesgoIncumplido
|
|||
|
Impacto
Impact
|
Posible efecto del cambio en las operaciones empresariales, clasificado en una escala como Alto, Medio o Bajo. | ||
|
Descripción
El impacto mide el posible efecto en la empresa si la solicitud de cambio no se gestiona correctamente. Junto con la urgencia, es un factor clave para determinar la prioridad general del cambio. Analizar los datos por impacto ayuda a garantizar que los cambios que afectan a servicios críticos se gestionen con el cuidado adecuado. El Dashboard 'Critical Change Performance' utiliza este atributo para identificar y supervisar los cambios con un alto impacto empresarial. También permite comprobar la coherencia de las evaluaciones de riesgos y garantizar que los cambios de alto impacto no reciban una clasificación de riesgo baja sin justificación.
Por qué es importante
Ayuda a priorizar los cambios según su posible efecto en la empresa y permite comprobar que los cambios de alto impacto se gestionen con la debida diligencia.
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. En este caso, se espera que sea ServiceNow, pero es un campo fundamental para la gobernanza de datos y para situaciones en las que se combinan datos de varios sistemas. En el análisis, permite mantener clara la trazabilidad de los datos y validar su origen. En las organizaciones que utilizan varias herramientas ITSM o sistemas integrados, este atributo permite filtrar y comparar procesos de distintas plataformas.
Por qué es importante
Proporciona una trazabilidad clara de los datos y garantiza que se documente su origen, algo esencial para la gobernanza de datos y el análisis de varios sistemas.
Dónde obtenerlo
Suele ser 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 por 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. Es un KPI clave para medir la velocidad general del proceso. Se utiliza en el Dashboard «Flujo integral del proceso de cambios» para ofrecer una visión general del rendimiento del proceso. Analizar las tendencias del tiempo de ciclo y compararlas según distintas dimensiones, como el tipo de cambio o la prioridad, ayuda a las organizaciones a encontrar oportunidades para mejorar estratégicamente sus procesos.
Por qué es importante
Mide la duración integral del proceso de cambios y ofrece un indicador clave de su velocidad y eficiencia generales.
Dónde obtenerlo
Se calcula por caso durante el análisis de datos, restando el StartTime mínimo del StartTime máximo de cada CaseId.
Ejemplos
60480012096002592000
|
|||
|
Última actualización de los 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 conocer la actualidad de los datos analizados. Quienes analizan los datos utilizan esta marca de tiempo para confirmar que trabajan con información actualizada y saber cuándo se obtuvieron los datos. Es especialmente importante para los Dashboards operativos que supervisan el rendimiento de los procesos en curso, ya que ayuda a evitar decisiones basadas en datos desactualizados.
Por qué es importante
Indica si los datos están actualizados y garantiza que los análisis y Dashboards se basen en información vigente y pertinente.
Dónde obtenerlo
Este campo de metadatos se genera durante el proceso de extracción y transformación de datos (ETL) e indica cuándo se extrajeron los datos.
Ejemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Urgencia
Urgency
|
La rapidez con la que debe resolverse un cambio, valorada en una escala como Alta, Media o Baja. | ||
|
Descripción
La urgencia indica con qué rapidez debe implementarse un cambio. Refleja la sensibilidad temporal de la solicitud desde la perspectiva del negocio. 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. Permite investigar por qué ciertos cambios se consideran urgentes y si el proceso los gestiona eficazmente sin comprometer la estabilidad. También ayuda a determinar si la organización trabaja con demasiada frecuencia de forma reactiva y con un alto nivel de urgencia.
Por qué es importante
Aporta contexto sobre la sensibilidad temporal de un cambio y permite analizar si el proceso gestiona eficazmente las solicitudes urgentes.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: urgency
Ejemplos
1 - Alto2 - Medio3 - Bajo
|
|||
|
Usuario asignado
AssignedToUser
|
Persona responsable de la solicitud de cambio en un momento determinado. | ||
|
Descripción
Este atributo identifica a la persona asignada para trabajar en la solicitud de cambio. Puede cambiar varias veces durante el ciclo de vida de la solicitud, a medida que esta pasa por distintas etapas y equipos. Analizar los datos por usuario ayuda a comprender la distribución de la carga de trabajo y el rendimiento individual, así como a identificar necesidades de formación. También es clave para analizar las transferencias de trabajo, especialmente si se combina con el grupo de asignación, ya que permite ver con qué eficiencia se transfiere el trabajo entre personas.
Por qué es importante
Ayuda a hacer un seguimiento de la carga de trabajo y el rendimiento de cada persona, y es fundamental para analizar las demoras en las transferencias entre distintos recursos.
Dónde obtenerlo
Tabla de ServiceNow: change_request, campo: assigned_to
Ejemplos
Beth AnglinDavid LooAbel Tuter
|
|||
Actividades de gestión de cambios
| Actividad | Descripción | ||
|---|---|---|---|
|
Cambio aprobado
|
La solicitud de cambio ha recibido todas las autorizaciones necesarias para pasar a las fases de programación e implementación. Es un hito fundamental que se registra 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 la toma de decisiones.
Dónde obtenerlo
Se infiere cuando el campo 'approval' de la tabla change_request cambia a 'approved'. La marca de tiempo se obtiene del historial de auditoría de este cambio.
Capturar
Registre la marca de tiempo cuando el campo 'approval' pase a 'approved'.
Tipo de evento
inferred
|
|||
|
Cambio cancelado
|
La solicitud de cambio se ha retirado o cancelado antes de completar la implementación. Este es un estado final alternativo que se registra cuando el estado se establece en 'Canceled'. | ||
|
Por qué es importante
Analizar los cambios cancelados puede revelar ineficiencias del proceso, como solicitudes innecesarias o solicitudes que permanecen demasiado tiempo pendientes de aprobación y quedan obsoletas.
Dónde obtenerlo
Se infiere cuando el campo 'state' de la tabla change_request se establece en 'Canceled'. La marca de tiempo se obtiene del registro de auditoría de este cambio de estado.
Capturar
Registre la marca de tiempo cuando el campo 'state' se actualice a 'Canceled'.
Tipo de evento
inferred
|
|||
|
Cambio cerrado
|
La solicitud de cambio se ha completado y revisado correctamente, y ahora se considera finalizada. Este es el principal estado final de éxito del proceso y se registra 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 de fin para medir la duración integral del proceso y el cumplimiento de los SLA.
Dónde obtenerlo
Se infiere cuando el campo 'state' de la tabla change_request se establece en 'Closed'. La marca de tiempo se obtiene del historial de auditoría de este cambio de estado final.
Capturar
Registre la marca de tiempo cuando el campo 'state' se actualice a 'Closed'.
Tipo de evento
inferred
|
|||
|
Cambio implementado
|
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 solicitud de cambio pasa de 'Implement' a 'Review'. | ||
|
Por qué es importante
Este es un hito fundamental 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 cuando el estado pasa de 'Implement' a un estado posterior, como 'Review'. La marca de tiempo se obtiene del historial de auditoría del campo 'state' en la tabla change_request.
Capturar
Identifique cuándo el campo 'state' cambia de 'Implement' a 'Review'.
Tipo de evento
inferred
|
|||
|
Cambio programado
|
Se han asignado fechas planificadas de inicio y fin al cambio aprobado, que ya figura oficialmente en el calendario de implementación. Se infiere cuando el estado de la solicitud de cambio pasa a 'Scheduled'. | ||
|
Por qué es importante
Esta actividad separa las etapas de planificación y aprobación de la fase de implementación activa. El tiempo que el cambio permanece en este estado puede indicar demoras entre la aprobación y el inicio del trabajo.
Dónde obtenerlo
Se infiere cuando el campo 'state' de la tabla change_request cambia a 'Scheduled'. La marca de tiempo se obtiene de la entrada correspondiente del registro de auditoría.
Capturar
Realice un seguimiento de los cambios del campo state a 'Scheduled' en el historial de auditoría de la tabla change_request.
Tipo de evento
inferred
|
|||
|
Riesgo e impacto evaluados
|
Representa la finalización del análisis de riesgos e impacto de la solicitud de cambio. Es un hito fundamental antes de solicitar la aprobación y suele inferirse cuando el cambio pasa del estado 'Assess' a 'Authorize' o 'Awaiting Approval'. | ||
|
Por qué es importante
Registrar la duración de la fase de evaluación es clave para el KPI 'Avg. Risk Assessment Cycle Time'. Permite estandarizar el proceso de evaluación e identificar dónde los análisis tardan demasiado.
Dónde obtenerlo
Se infiere cuando el campo 'state' de la tabla change_request cambia de 'Assess' a 'Authorize'. La marca de tiempo del evento se obtiene del registro de auditoría de este cambio de estado.
Capturar
Identifique cuándo el campo 'state' cambia de 'Assess' a un estado posterior, como 'Authorize'.
Tipo de evento
inferred
|
|||
|
Solicitud de cambio creada
|
Esta actividad marca la creación de un nuevo registro de solicitud de cambio en el sistema. Es el inicio oficial del proceso de gestión de cambios y se registra 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 las siguientes permite conocer el tiempo de entrega total e identificar demoras desde las primeras etapas 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.
Capturar
Use la marca de tiempo sys_created_on de la tabla change_request.
Tipo de evento
explicit
|
|||
|
Aprobación solicitada
|
Esta actividad indica que la solicitud de cambio se ha enviado formalmente para su aprobación, normalmente a una persona gerente o a un comité asesor de cambios (CAB). El evento se registra cuando el estado de aprobación de la solicitud de cambio se establece en 'requested'. | ||
|
Por qué es importante
Esto marca el inicio del ciclo de aprobación. Medir el tiempo transcurrido desde este evento hasta 'Change Approved' permite calcular directamente el KPI 'Average Change Approval Time'.
Dónde obtenerlo
Se infiere cuando el campo 'approval' de la tabla change_request cambia a 'requested'. La marca de tiempo se registra en la tabla sys_audit para este campo.
Capturar
Marca de tiempo del momento en que el campo 'approval' de la tabla change_request se establece en 'requested'.
Tipo de evento
inferred
|
|||
|
Cambio pendiente de evaluación
|
La solicitud de cambio se ha enviado y está a la espera de una evaluación técnica y empresarial. Por lo general, se infiere cuando el estado de la solicitud cambia a 'Assess' o a un estado similar, lo que indica que ha salido de la fase de borrador. | ||
|
Por qué es importante
Esta actividad permite medir el tiempo inicial de transferencia de la persona solicitante al equipo de evaluación. Las demoras en esta etapa pueden indicar problemas con la calidad de los datos iniciales 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.
Capturar
Realice un seguimiento de los cambios del campo state a 'Assess' en el historial de auditoría de la tabla change_request.
Tipo de evento
inferred
|
|||
|
Cambio reabierto
|
La solicitud de cambio ha vuelto a un estado anterior, como 'Implement' o 'Assess', después de llegar a una etapa posterior. Este evento se infiere a partir de una transición de estado no lineal e indica que hay que repetir trabajo. | ||
|
Por qué es importante
Esta actividad es fundamental para identificar ciclos de retrabajo y calcular el KPI 'Change Rework Rate'. La reapertura frecuente de solicitudes indica problemas con la calidad de la implementación, las pruebas o la planificación.
Dónde obtenerlo
Se infiere al analizar 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 que el cambio se reabrió.
Capturar
Detecte una transición hacia atrás y fuera de secuencia en el historial del campo 'state'.
Tipo de evento
inferred
|
|||
|
Cambio rechazado
|
La persona aprobadora o el CAB ha rechazado la solicitud de cambio. Esta actividad representa un estado terminal para la solicitud, salvo que se modifique y se vuelva a enviar. Se registra cuando el campo 'approval' se establece en 'rejected'. | ||
|
Por qué es importante
El seguimiento de los rechazos ayuda a identificar motivos frecuentes, como información incompleta o un nivel de riesgo elevado. Este análisis puede mejorar la calidad de futuras solicitudes de cambio.
Dónde obtenerlo
Se infiere cuando el campo 'approval' de la tabla change_request cambia a 'rejected'. La marca de tiempo se obtiene del historial de auditoría.
Capturar
Registre la marca de tiempo cuando el campo 'approval' pase a 'rejected'.
Tipo de evento
inferred
|
|||
|
Implementación iniciada
|
Ya se está trabajando en la implementación del cambio. Se registra cuando el estado de la solicitud de cambio se actualiza a 'Implement', lo que indica el paso 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 cuando el campo 'state' de la tabla change_request cambia a 'Implement'. La marca de tiempo se obtiene del registro de auditoría de esta transición de estado.
Capturar
Registre la marca de tiempo del cambio de estado a 'Implement' a partir del 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 registra cuando el estado de la solicitud de cambio se establece en 'Review'. | ||
|
Por qué es importante
Analizar la duración de la fase de revisión ayuda a identificar demoras en la validación del éxito del cambio. También permite detectar cambios que incumplen los estándares porque se omite este paso.
Dónde obtenerlo
Se infiere cuando el campo 'state' de la tabla change_request cambia a 'Review'. La marca de tiempo se obtiene del registro de auditoría de este cambio de estado.
Capturar
Registre la marca de tiempo del cambio de estado a 'Review' a partir del historial de auditoría de change_request.
Tipo de evento
inferred
|
|||
Guías de extracción
¿Todo listo para empezar?
Utilice este Template para preparar sus datos y obtener información sobre el proceso de gestión de cambios en ServiceNow. Empiece hoy mismo a optimizarlo para mejorar su eficiencia.
¡Evite cambios fallidos y mejore hoy mismo los resultados en ServiceNow!
Localice los cuellos de botella y alcance fácilmente una tasa de éxito del 95 % en los cambios.
No se requiere tarjeta de crédito. Configure todo en minutos.