Su Template de datos de gestión de cambios

ServiceNow
Su Template de datos de gestión de cambios

Su Template de datos de gestión de cambios

Este Template ofrece un enfoque estructurado para recopilar los datos esenciales necesarios para aplicar Process Mining de forma eficaz a su Workflow de gestión de cambios. Describe los atributos y las actividades recomendados que deben registrarse, junto con orientación práctica para extraer los datos. Utilice este recurso para preparar sus datos para un análisis y una optimización exhaustivos.
  • Atributos recomendados que debe recopilar
  • Actividades clave que debe supervisar para descubrir el proceso con precisión
  • Orientación para extraer datos de ServiceNow
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos de Change Management

Estos son los campos de datos recomendados para incluir en su registro de eventos y realizar un análisis completo de su proceso de gestión de cambios.
3 Obligatorio 7 Recomendado 9 Opcional
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
Obligatorio Recomendado Opcional

Actividades de Change Management

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir con precisión el proceso de gestión de cambios.
7 Recomendado 6 Opcional
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
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de ServiceNow

¿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 %.

Inicie su prueba gratuita

No necesita tarjeta de crédito; la configuración solo tarda unos minutos.