> Mejora continua de procesos > Gestión de solicitudes de servicio > Ivanti Service Manager > Template de datos

Su Template de datos para la gestión de solicitudes de servicio

Ivanti Service Manager

Atributos de la gestión de solicitudes de servicio (21) Actividades de la gestión de solicitudes de servicio (14) Guías de extracción (2)

Su Template de datos para la gestión de solicitudes de servicio

Esta plantilla ofrece una guía completa para recopilar los datos esenciales necesarios para realizar un Process Mining eficaz de la gestión de sus solicitudes de servicio. Detalla los atributos fundamentales que debe recopilar, las actividades clave que debe registrar e incluye recomendaciones prácticas para extraer esta información de su sistema. Utilice este recurso para crear un registro de eventos sólido para su análisis.

Atributos recomendados para un análisis completo
Actividades clave que debe registrar para descubrir el proceso
Recomendaciones para extraer datos de su sistema de origen

¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Descargar Template

Atributos de la gestión de solicitudes de servicio

Estos son los campos de datos recomendados para incluir en su registro de eventos y obtener un análisis completo de su proceso de gestión de solicitudes de servicio.

5 Obligatorio 9 Recomendado 7 Opcional

	Nombre	Descripción
	Hora del evento EventTime	La marca de tiempo que indica cuándo tuvo lugar una actividad o un evento concreto.
Descripción La hora del evento, también conocida como hora de inicio, es la fecha y hora exactas en que se registró una actividad en el sistema. Esta marca de tiempo es fundamental para ordenar correctamente los eventos y constituye la base de todos los análisis de process mining basados en el tiempo, como el cálculo de tiempos de ciclo, tiempos de espera y duraciones de actividades. Por qué es importante Esta marca de tiempo es esencial para ordenar cronológicamente los eventos y calcular todas las métricas basadas en la duración, que son clave para el análisis del rendimiento. Dónde obtenerlo Se encuentra en los registros de auditoría, las entradas del diario, por ejemplo Journal.CreatedDateTime, o los registros de cambios de estado asociados a la solicitud de servicio. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ID de solicitud de servicio ServiceRequestID	El identificador único de cada solicitud de servicio.
Descripción El ID de solicitud de servicio identifica de forma única cada solicitud individual enviada por un usuario o un sistema. Actúa como hilo central que conecta todos los eventos posteriores, desde el registro inicial hasta el cierre final, y permite analizar de principio a fin el recorrido de cada solicitud de servicio. Por qué es importante Este es el identificador de caso esencial que conecta todas las actividades relacionadas en una única instancia de proceso y permite analizar el proceso de principio a fin. Dónde obtenerlo Es la clave principal del objeto de negocio Service Request, que suele aparecer como ServiceReqNumber en la tabla ServiceReq. Ejemplos SR-0012345SR-0012346SR-0012347
	Nombre de la actividad ActivityName	El nombre del evento o la tarea que tuvo lugar en un momento concreto del ciclo de vida de la solicitud de servicio.
Descripción Este atributo describe un paso específico o un cambio de estado dentro del proceso de solicitud de servicio, como 'Request Submitted for Approval' o 'Service Request Resolved'. Analizar la secuencia y la frecuencia de las actividades es fundamental para comprender el flujo del proceso, identificar cuellos de botella y descubrir desviaciones respecto al procedimiento estándar. Por qué es importante Define los pasos del mapa de procesos y permite visualizar y analizar el flujo del proceso, incluida la identificación de retrabajos, cuellos de botella y desviaciones. Dónde obtenerlo Normalmente se obtiene de cambios de estado, entradas del diario o descripciones de eventos del registro de auditoría en Ivanti Service Manager. Ejemplos Solicitud de servicio creadaSolicitud aprobadaSolicitud de servicio resueltaSolicitud de servicio cerrada
	Sistema de origen SourceSystem	El sistema del que se extrajeron los datos.
Descripción Este atributo identifica el origen de los datos del proceso. En esta vista, el valor será constante e indicará que todos los datos proceden de Ivanti Service Manager. Esto es importante en entornos en los que pueden combinarse datos de varios sistemas, ya que garantiza una trazabilidad y un contexto claros. Por qué es importante Proporciona un contexto esencial sobre la procedencia de los datos y garantiza que los análisis se atribuyan correctamente al sistema de origen específico, especialmente en entornos con varios sistemas. Dónde obtenerlo Normalmente es un valor estático que se añade durante el proceso de extracción de datos para etiquetar el origen del conjunto de datos. Ejemplos Ivanti Service Manager
	Última actualización de datos LastDataUpdate	La marca de tiempo de la actualización más reciente de los datos desde el sistema de origen.
Descripción Este atributo indica la fecha y hora en que se extrajeron por última vez los datos de Ivanti Service Manager. Proporciona contexto sobre la actualidad de los datos analizados y garantiza que los usuarios conozcan el periodo cubierto por el análisis y cuándo pueden esperar la próxima actualización. Por qué es importante Informa a los usuarios sobre la actualidad de los datos, un aspecto fundamental para tomar decisiones basadas en la información más reciente disponible sobre el rendimiento del proceso. Dónde obtenerlo Este valor se genera y se incorpora al conjunto de datos en el momento de extraer los datos. Ejemplos 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Agente asignado AssignedAgent	El usuario o agente asignado a la solicitud de servicio.
Descripción El agente asignado es la persona responsable de trabajar en la solicitud de servicio. Este atributo permite realizar análisis a nivel individual, útiles para gestionar el rendimiento, equilibrar la carga de trabajo e identificar oportunidades de formación. Registrar las reasignaciones entre agentes es clave para calcular KPI como «Promedio de reasignaciones por solicitud» y comprender las ineficiencias del proceso. Por qué es importante Permite analizar la carga de trabajo individual, el rendimiento y los patrones de reasignación, que pueden indicar problemas de formación, competencias o en el enrutamiento inicial. Dónde obtenerlo Normalmente se encuentra en un campo como «Owner» del objeto Service Request. Puede cambiar con cada reasignación y debe registrarse en el registro de eventos. Ejemplos Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Equipo asignado AssignedTeam	El equipo o grupo de soporte asignado actualmente para gestionar la solicitud de servicio.
Descripción Este atributo identifica al equipo responsable de gestionar la solicitud de servicio en un momento determinado. Analizar los traspasos entre equipos, el tiempo dedicado por cada equipo y el volumen de solicitudes gestionadas por distintos equipos es fundamental para comprender la distribución de la carga de trabajo, identificar cuellos de botella y evaluar el rendimiento de los equipos. También respalda directamente los Dashboards relacionados con el cumplimiento del SLA y la carga de trabajo de los agentes. Por qué es importante Registra la responsabilidad y las transferencias, lo que ayuda a analizar los retrasos entre equipos, el equilibrio de la carga de trabajo y qué equipos actúan como cuellos de botella del proceso. Dónde obtenerlo Esta información suele almacenarse en un campo como «OwnerTeam» del objeto Service Request o en registros de asignación relacionados. Ejemplos Mesa de ayuda de TIOperaciones de redSoporte de RR. HH.Gestión de instalaciones
	Estado de la solicitud de servicio ServiceRequestStatus	El estado de la solicitud de servicio en el momento del evento.
Descripción Este atributo registra el estado de la solicitud de servicio, como «Registrada», «En curso», «Pendiente», «Resuelta» o «Cerrada». Los cambios de estado suelen definir las actividades del registro del proceso. Analizar el tiempo empleado en cada estado puede revelar cuellos de botella, por ejemplo, si las solicitudes permanecen demasiado tiempo en estado «Pendiente». Por qué es importante Proporciona una instantánea del estado de la solicitud en cualquier momento, algo esencial para calcular el tiempo empleado en estados específicos e identificar interrupciones del proceso. Dónde obtenerlo Un campo estándar del objeto Service Request, normalmente denominado «Status». Ejemplos RegistradoActivoEn espera del clienteAtendidoCerrado
	Estado del SLA SLAStatus	Indica si la solicitud de servicio se resolvió dentro de la fecha límite del SLA.
Descripción Este atributo derivado marca cada solicitud de servicio como «Cumplido» o «Incumplido» según su tiempo de resolución en relación con la fecha límite del SLA. Es la base del Dashboard «Rendimiento del cumplimiento del SLA» y del KPI «Tasa de cumplimiento del acuerdo de nivel de servicio». La lógica compara ResolutionDateTime con SLADeadline para cada caso. Por qué es importante Mide directamente el rendimiento frente a los compromisos de servicio, algo fundamental para evaluar la calidad del servicio y mantener la confianza de los usuarios. Dónde obtenerlo Se calcula comparando «ResolutionDateTime» con «SLADeadline». Si ResolutionDateTime <= SLADeadline, el estado es «Cumplido»; de lo contrario, es «Incumplido». Ejemplos CumplidoIncumplido
	Fecha límite del SLA SLADeadline	La marca de tiempo antes de la cual se espera resolver la solicitud de servicio.
Descripción La fecha límite del SLA es la fecha y hora calculadas antes de las cuales debe resolverse una solicitud de servicio para cumplir el acuerdo de nivel de servicio. Este objetivo suele determinarse según factores como la prioridad y el tipo de solicitud. Comparar la hora real de resolución con esta fecha límite permite medir el cumplimiento del SLA. Por qué es importante Es el punto de referencia con el que se mide el rendimiento real y respalda directamente el cálculo de las tasas de cumplimiento del SLA y la identificación de solicitudes en riesgo. Dónde obtenerlo A menudo es un campo calculado en Ivanti, almacenado en campos relacionados con el acuerdo de nivel de servicio o la oferta, como «ResolutionTargetDateTime». Ejemplos 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Hora de finalización del evento EventEndTime	La marca de tiempo que indica cuándo se completó una actividad.
Descripción La hora de finalización del evento marca la conclusión de una actividad. La duración entre la hora del evento (inicio) y la hora de finalización del evento representa el tiempo de procesamiento de esa actividad específica. Esto es fundamental para identificar qué pasos del proceso consumen más tiempo y detectar ineficiencias y áreas de mejora. Por qué es importante Permite calcular la duración de cada actividad, algo esencial para identificar cuellos de botella del proceso y tareas de larga duración. Dónde obtenerlo Puede no existir como campo independiente. A menudo corresponde a la hora de inicio de la actividad siguiente de la secuencia para el mismo caso. Ejemplos 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Marca de tiempo de resolución ResolutionDateTime	La fecha y hora en que la solicitud de servicio se resolvió oficialmente.
Descripción Este atributo a nivel de caso marca la marca de tiempo final en la que se prestó el servicio o se solucionó el problema, antes de cerrar formalmente la solicitud. Esta marca de tiempo es el punto final principal para calcular el tiempo de ciclo integral de una solicitud de servicio. Es un componente fundamental para medir la eficiencia general del proceso y el cumplimiento del SLA. Por qué es importante Define el punto final para calcular el tiempo de ciclo del proceso principal, un indicador clave del rendimiento de la prestación del servicio. Dónde obtenerlo Un campo de marca de tiempo específico del objeto Service Request, a menudo denominado «ResolvedDateTime» o similar. Ejemplos 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Prioridad Priority	El nivel de prioridad asignado a la solicitud de servicio.
Descripción La prioridad indica la urgencia de una solicitud de servicio, normalmente en una escala como «Baja», «Media», «Alta» o «Crítica». Este atributo es fundamental para evaluar si el proceso acelera eficazmente las solicitudes de alta prioridad. El análisis suele comparar los tiempos de ciclo y el cumplimiento del SLA entre distintos niveles de prioridad para garantizar que las reglas de priorización funcionan según lo previsto. Por qué es importante Es fundamental para evaluar la eficacia de la estrategia de priorización y garantizar que las solicitudes de alta prioridad se resuelvan más rápido que las de baja prioridad. Dónde obtenerlo Un campo estándar del objeto Service Request, normalmente denominado «Priority». Ejemplos 1 - Crítica2 - Alta3 - Media4 - Baja
	Tipo de solicitud de servicio ServiceRequestType	La clasificación o categoría de la solicitud de servicio.
Descripción Este atributo categoriza la solicitud de servicio, por ejemplo, «Solicitud de hardware», «Instalación de software» o «Restablecimiento de contraseña». Es una dimensión fundamental para el análisis, ya que permite comparar el rendimiento del proceso, los tiempos de ciclo y el cumplimiento del SLA entre distintos tipos de servicio. Comprender estas diferencias ayuda a adaptar las mejoras del proceso y asignar los recursos de forma más eficaz. Por qué es importante Segmentar el proceso por tipo de solicitud permite realizar análisis específicos y descubrir si ciertos tipos de solicitudes son más propensos a sufrir retrasos, retrabajo o incumplimientos del SLA. Dónde obtenerlo Probablemente sea un campo del objeto de negocio Service Request, a menudo denominado «Service» o «Category». Consulte la documentación de Ivanti Service Manager para conocer nombres de campos específicos, como «SvcReqTmplLink_Category». Ejemplos Solicitud de hardware nuevoAcceso al softwareModificación de cuentaConsulta de información
	Canal Channel	El método o canal mediante el cual se envió la solicitud de servicio.
Descripción El canal indica cómo se creó la solicitud de servicio, por ejemplo, a través del portal de autoservicio, correo electrónico, teléfono o automáticamente mediante otro sistema. Analizar el volumen de solicitudes y los tiempos de resolución por canal puede proporcionar información sobre qué canales son más eficientes y cuáles requieren mejoras del proceso o formación para los usuarios. Por qué es importante Ayuda a comprender el comportamiento de los usuarios y la eficiencia de los canales, lo que puede orientar las decisiones sobre la estrategia de prestación del servicio y las oportunidades de automatización. Dónde obtenerlo A menudo se almacena en un campo de tipo «Source» o «CreatedBy» del objeto Service Request. Ejemplos AutoservicioCorreo electrónicoTeléfonoEntrada directa
	Categoría de resolución ResolutionCategory	Una clasificación de la resolución proporcionada para la solicitud de servicio.
Descripción La categoría de resolución ofrece una forma estructurada de clasificar cómo se resolvió finalmente una solicitud de servicio. A menudo se trata de una clasificación jerárquica, por ejemplo, categoría y subcategoría, que ayuda en el análisis de causas raíz y la elaboración de informes de tendencias. Puede poner de relieve problemas recurrentes o tipos habituales de acciones de cumplimiento, que pueden utilizarse para mejorar los servicios o crear artículos para la base de conocimientos. Por qué es importante Proporciona información sobre la naturaleza de las resoluciones y ayuda a identificar problemas comunes, oportunidades de mejora del servicio y candidatos para la automatización. Dónde obtenerlo A menudo se almacena en campos de categorización que se completan al resolver la solicitud, como «ResolutionCategory» o un campo personalizado de código de cierre. Ejemplos Se requiere capacitación del usuarioSoftware implementadoHardware reparadoAcceso concedido
	Departamento solicitante RequestorDepartment	El departamento de la organización al que pertenece el usuario que envió la solicitud de servicio.
Descripción Este atributo identifica el departamento del empleado o sistema que inició la solicitud de servicio, como «Ventas», «Finanzas» o «Recursos Humanos». Permite analizar la calidad y la demanda del servicio en distintas áreas de la organización. Por ejemplo, ayuda a identificar si determinados departamentos experimentan tiempos de resolución más largos o envían un mayor volumen de solicitudes. Por qué es importante Permite analizar el consumo y la calidad del servicio por unidad de negocio, y ayuda a identificar problemas o tendencias específicos de cada departamento. Dónde obtenerlo Esta información suele obtenerse del perfil de usuario del solicitante, vinculado a la solicitud de servicio. El campo podría ser «Department» en el objeto Profile.Employee. Ejemplos FinanzasVentasMarketingTecnologías de la información
	Es retrabajo IsRework	Un indicador booleano que señala si la solicitud de servicio implicó actividades de retrabajo.
Descripción Este indicador calculado se establece en true si una solicitud de servicio muestra señales de retrabajo, por ejemplo, si se vuelve a abrir después de resolverse o si determinadas actividades se repiten en un bucle. Simplifica el cálculo del KPI «Service Request Rework Rate» y ayuda a filtrar las instancias de proceso ineficientes en Dashboards como «Rework and Reassignment Flows». Por qué es importante Ayuda a identificar y cuantificar fácilmente el volumen de solicitudes que requieren un esfuerzo adicional no planificado, poniendo de relieve problemas de calidad y eficiencia. Dónde obtenerlo Se deriva de los datos. La lógica puede basarse en que el atributo «ReopenCount» sea mayor que cero o en la detección de secuencias de actividades específicas, como varios eventos «Assigned to Agent». Ejemplos truefalse
	Nombre del proveedor VendorName	El nombre del proveedor externo que participa en la resolución de la solicitud.
Descripción Este atributo identifica al proveedor externo contratado para ayudar a gestionar o completar una solicitud de servicio. Es esencial para el Dashboard «Duración de la actividad del proveedor externo», ya que permite medir y comparar el rendimiento de distintos proveedores. Su seguimiento ayuda a gestionar las relaciones con los proveedores e identificar cuellos de botella causados por dependencias externas. Por qué es importante Permite analizar el rendimiento de terceros y su impacto en los tiempos generales de resolución de las solicitudes de servicio, lo que respalda la gestión de proveedores. Dónde obtenerlo Podría ser un campo de un objeto de tarea asociado a la solicitud de servicio o un campo específico de la propia solicitud si se asigna un proveedor. Ejemplos Soporte de DellConsultoría de OracleMicrosoft Premiernull
	Número de asignaciones AssignmentCount	El número total de veces que se asignó o reasignó una solicitud de servicio.
Descripción Esta métrica calculada cuenta el número de actividades relacionadas con asignaciones, por ejemplo, «Assigned to Team» y «Assigned to Agent», para cada solicitud de servicio. Un número elevado de reasignaciones, conocido a menudo como «ticket ping-pong», indica ineficiencias en el enrutamiento, falta de resolución en el primer contacto o responsabilidades de equipo poco claras. Este atributo es esencial para el KPI «Promedio de reasignaciones por solicitud». Por qué es importante Cuantifica las transferencias ineficientes y los problemas de enrutamiento. Un valor elevado es un indicador claro de tiempos de resolución prolongados y frustración de los usuarios. Dónde obtenerlo Se calcula contando las apariciones de actividades relacionadas con asignaciones para cada ServiceRequestID único durante la preparación de los datos. Ejemplos 12345
	Número de reaperturas ReopenCount	El número de veces que se ha reabierto una solicitud de servicio resuelta.
Descripción Este atributo es un contador que aumenta cada vez que una solicitud de servicio pasa del estado «Resuelta» o «Cerrada» al estado «Activa». Un número elevado de reaperturas indica claramente una baja calidad de resolución en el primer intento, soluciones incompletas o problemas recurrentes. Respaldа directamente el KPI «Tasa de retrabajo de solicitudes de servicio». Por qué es importante Mide directamente el retrabajo y es un indicador clave de la calidad de la resolución. Los valores elevados sugieren que la solución inicial no fue eficaz. Dónde obtenerlo Normalmente es un campo contador del objeto Service Request que una regla de negocio incrementa cuando el estado cambia de la forma correspondiente. Podría denominarse «ReopenCounter». Ejemplos 0123

Obligatorio Recomendado Opcional

Actividades de la gestión de solicitudes de servicio

Estos son los pasos esenciales y los hitos del proceso que debe capturar en su registro de eventos para descubrir y analizar el proceso con precisión.

5 Recomendado 9 Opcional

	Actividad	Descripción
	Solicitud asignada a un agente	Un agente específico asume la responsabilidad de la solicitud de servicio. Esta actividad suele inferirse cuando el campo 'Owner', que designa al agente individual, se completa o actualiza por primera vez.
Por qué es importante Esto marca el final del tiempo inicial de espera o de cola. Medir la duración anterior a esta actividad ayuda a identificar problemas de asignación de recursos y respalda el Dashboard de carga de trabajo de los agentes. Dónde obtenerlo Se infiere a partir de la cumplimentación o el cambio del campo 'Owner' en el registro de Service Request, tal como aparece en el historial de auditoría. Recopilar La primera marca de tiempo en la que el campo 'Owner' se completa con el nombre de un agente después de la creación o la asignación al equipo. Tipo de evento inferred
	Solicitud asignada a un equipo	La solicitud de servicio se asigna a un equipo de soporte específico para su gestión. Esto se captura observando la cumplimentación o el cambio del campo 'OwnerTeam' en el registro de Service Request.
Por qué es importante Este evento es esencial para analizar el rendimiento a nivel de equipo, la distribución de la carga de trabajo y los tiempos de transferencia entre equipos. Ayuda a identificar qué equipos actúan como cuellos de botella en el proceso. Dónde obtenerlo Se registra mediante los cambios en el campo 'OwnerTeam' dentro del historial de auditoría o el diario de la solicitud de servicio. Recopilar Un evento de actualización del campo 'OwnerTeam', que normalmente queda registrado en un registro de auditoría. Tipo de evento explicit
	Solicitud de servicio cerrada	La solicitud de servicio se ha cerrado oficialmente y no se pueden realizar más acciones. Esto suele ocurrir automáticamente después de un periodo determinado en el estado 'Resolved' y representa la conclusión final del ciclo de vida.
Por qué es importante Esta actividad constituye el final definitivo del proceso. El tiempo transcurrido entre 'Resolved' y 'Closed' puede poner de manifiesto retrasos en la confirmación o en los procesos automatizados del sistema. Dónde obtenerlo Se infiere a partir de un cambio en el campo 'Status' del registro de Service Request a 'Closed', junto con la marca de tiempo correspondiente. Recopilar Detectar la actualización del campo 'Status' a 'Closed' a partir del historial de auditoría. Tipo de evento inferred
	Solicitud de servicio creada	Esta actividad marca el inicio del ciclo de vida de la solicitud de servicio, cuando se presenta formalmente una nueva solicitud y se registra en Ivanti. El evento se captura cuando se crea un nuevo registro en el objeto de negocio Service Request, lo que genera un ID de solicitud de servicio único.
Por qué es importante Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde este punto hasta la resolución es fundamental para medir el tiempo de ciclo general y la eficiencia del proceso. Dónde obtenerlo Se captura a partir de la marca de tiempo de creación del registro de Service Request, por ejemplo, el campo CreatedDateTime del objeto de negocio ServiceReq. Recopilar El evento de creación del registro en la tabla ServiceReq, identificado por su marca de tiempo de creación. Tipo de evento explicit
	Solicitud de servicio resuelta	La solicitud de servicio se considera resuelta y la solución se ha entregado al usuario. Este es un hito principal que se captura mediante un cambio de estado a 'Resolved' y que suele detener el contador del SLA.
Por qué es importante Este es un punto final crítico para medir el tiempo de resolución y el cumplimiento del SLA. La duración desde la creación hasta esta actividad es un KPI fundamental del rendimiento del proceso. Dónde obtenerlo Se infiere a partir de un cambio en el campo 'Status' del registro de Service Request a 'Resolved', junto con la marca de tiempo correspondiente. Recopilar Detectar la actualización del campo 'Status' a 'Resolved' a partir del historial de auditoría. Tipo de evento inferred
	Información proporcionada por el usuario	El solicitante ha proporcionado la información necesaria, lo que permite al agente reanudar el trabajo. Esto se captura cuando la solicitud sale del estado 'Waiting for Customer' y vuelve a un estado activo.
Por qué es importante Este evento cierra el ciclo de las solicitudes de información. El tiempo transcurrido entre solicitar y recibir la información es un componente crítico de los retrasos del proceso y de los ciclos de retrabajo. Dónde obtenerlo Se infiere cuando el campo 'Status' de la solicitud de servicio cambia de un estado 'Waiting for Customer' a uno activo, como 'Active' o 'In Progress'. Recopilar Detectar un cambio de estado desde un estado 'waiting on user' a un estado activo. Tipo de evento inferred
	Información solicitada al usuario	El agente asignado necesita más información del solicitante para continuar con el cumplimiento. Esto se captura cuando el estado de la solicitud se actualiza a un estado como 'Waiting for Customer'.
Por qué es importante Esta actividad pone de manifiesto los retrasos causados por información inicial incompleta. Hacer un seguimiento de su frecuencia y duración es clave para el Análisis del impacto de las solicitudes de información y para identificar áreas de mejora del proceso. Dónde obtenerlo Se infiere a partir de un cambio de estado en el registro de Service Request a un estado como 'Waiting for Customer' o 'Pending'. Recopilar Detectar un cambio en el campo 'Status' a un estado designado como 'waiting on user'. Tipo de evento inferred
	Prioridad modificada	La prioridad de la solicitud de servicio se ha actualizado después de su creación inicial. Este evento se captura en el registro de auditoría o historial que realiza el seguimiento de los cambios a nivel de campo.
Por qué es importante Hacer un seguimiento de los cambios de prioridad es fundamental para la Vista general de la eficacia de la priorización. Ayuda a determinar si las escalaciones se gestionan correctamente y si la priorización inicial es precisa. Dónde obtenerlo Este es un evento explícito capturado en el historial de auditoría del registro de Service Request, que registra los cambios en el campo 'Priority'. Recopilar Un evento de actualización del campo 'Priority' registrado en el registro de auditoría del sistema. Tipo de evento explicit
	Proveedor externo involucrado	El cumplimiento de la solicitud de servicio se ha transferido a un proveedor externo o a un tercero. Normalmente se captura mediante un cambio de estado a 'Waiting for 3rd Party' o a un estado similar.
Por qué es importante Esta actividad es esencial para medir el rendimiento del proveedor y su impacto en el tiempo de ciclo general. Permite analizar los retrasos relacionados con proveedores y respalda el Dashboard de duración de las actividades de proveedores externos. Dónde obtenerlo Se infiere a partir de un cambio de estado en el registro de Service Request a un estado como 'Waiting for 3rd Party' o 'Pending Vendor'. Recopilar Detectar un cambio en el campo 'Status' a un estado designado como 'waiting on vendor'. Tipo de evento inferred
	Solicitud aprobada	La solicitud de servicio ha recibido todas las aprobaciones necesarias y ahora puede pasar a la fase de cumplimiento. Este evento se captura cuando el Workflow de aprobación finaliza correctamente y cambia el estado de la solicitud.
Por qué es importante Esta actividad marca un hito importante: señala el final de la fase de aprobación y el inicio del cumplimiento. Permite medir la eficiencia del propio proceso de aprobación. Dónde obtenerlo Se infiere a partir de un cambio de estado de 'Waiting for Approval' a 'Approved' o 'Fulfilled'. También puede ser un evento explícito registrado en el objeto de negocio FRS_Approval. Recopilar Un cambio en el campo 'Status' del registro de Service Request, que pasa de un estado de aprobación a uno activo. Tipo de evento inferred
	Solicitud de servicio cancelada	El usuario o un agente ha cancelado la solicitud de servicio antes de su resolución. Este es un estado final alternativo que se captura mediante un cambio de estado a 'Cancelled' o 'Withdrawn'.
Por qué es importante Esto representa una finalización no estándar del proceso. Analizar por qué se cancelan las solicitudes puede revelar problemas en el propio proceso de solicitud o cambios en las necesidades de los usuarios. Dónde obtenerlo Se infiere a partir de un cambio en el campo 'Status' del registro de Service Request a 'Cancelled'. Recopilar Detectar la actualización del campo 'Status' a 'Cancelled' a partir del historial de auditoría. Tipo de evento inferred
	Solicitud de servicio completada	El agente o el sistema han completado todas las tareas necesarias para cumplir la solicitud de servicio. Esto se captura mediante un cambio de estado a 'Fulfilled', que suele preceder al estado final 'Resolved'.
Por qué es importante Este hito marca la finalización del trabajo técnico o procedimental. Es un punto clave para medir el tiempo de gestión activa antes de la confirmación y el cierre finales. Dónde obtenerlo Se infiere a partir de un cambio en el campo 'Status' del registro de Service Request a 'Fulfilled'. Recopilar Un cambio en el campo 'Status' a 'Fulfilled' detectado en el historial del registro. Tipo de evento inferred
	Solicitud de servicio reabierta	Una solicitud de servicio previamente resuelta se ha reactivado porque el problema persiste o la solución no fue satisfactoria. Esto se captura cuando el estado cambia de 'Resolved' a un estado activo como 'Active' o 'Assigned'.
Por qué es importante Esta actividad es un indicador directo de retrabajo y de una baja calidad de resolución en el primer contacto. Analizar los eventos de reapertura ayuda a identificar debilidades del proceso y a mejorar el KPI de tasa de retrabajo de solicitudes de servicio. Dónde obtenerlo Se infiere a partir del historial de auditoría cuando el campo 'Status' cambia de 'Resolved' o 'Closed' a un estado activo. Recopilar Un cambio de estado desde un estado terminal ('Resolved', 'Closed') a un estado abierto ('Active', 'Assigned'). Tipo de evento inferred
	Solicitud enviada para aprobación	La solicitud de servicio se ha enviado para obtener las aprobaciones necesarias antes de poder completarse. Normalmente se infiere cuando el estado de la solicitud cambia a 'Submitted' o 'Pending Approval', lo que suele activar un Workflow de aprobación.
Por qué es importante El seguimiento de esta actividad ayuda a identificar retrasos en la fase de aprobación. Las esperas prolongadas en este punto pueden convertirse en un cuello de botella importante y afectar a los tiempos generales de resolución y a la satisfacción de los usuarios. Dónde obtenerlo Se infiere a partir de un cambio de estado en el registro de Service Request, probablemente a un estado como 'Submitted' o 'Waiting for Approval'. También puede obtenerse de los objetos de negocio FRS_Approval o FRS_ApprovalVoteTracking. Recopilar Un cambio en el campo 'Status' del registro de Service Request a un estado pendiente de aprobación. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Ivanti Service Manager

Pasos

Inicie sesión en Ivanti Service Manager con un rol que tenga acceso de lectura a Service Requests y a su historial de auditoría.
Acceda al espacio de trabajo Service Request desde el panel de navegación principal.
Este proceso requiere dos exportaciones de datos independientes que se combinarán externamente. La primera captura el evento de creación y los atributos principales; la segunda, el historial detallado de cambios.
Primera exportación (eventos de creación): Cree una nueva Saved Search sobre el objeto de negocio ServiceReq. Configure un filtro para CreatedDateTime que seleccione las solicitudes de servicio creadas durante el periodo de análisis deseado, por ejemplo, los últimos seis meses.
Configure las columnas de la búsqueda de creación para incluir RecId, ServiceReqNumber (para ServiceRequestID), CreatedDateTime (para EventTime), SvcReqTmplLink_Category (para ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime y TargetDateTime (para SLADeadline).
Ejecute la búsqueda y utilice la función de exportación de la cuadrícula, normalmente un icono parecido a un disco o una flecha, para exportar los datos a un archivo CSV. Asígnele el nombre ServiceRequests.csv.
Segunda exportación (eventos del historial de auditoría): Cree una nueva Saved Search, esta vez sobre el objeto de negocio FRS_data_audit_history, que registra los cambios de campos.
Filtre esta búsqueda para incluir únicamente los cambios relacionados con Service Requests. Añada un filtro en el que ParentObjectType sea igual a 'ServiceReq'. Añada también un filtro para AuditDate con el mismo periodo de análisis utilizado anteriormente.
Configure las columnas de la búsqueda de auditoría para incluir ParentLink_RecID (para vincularla con la solicitud de servicio), FieldName, OldValue, NewValue y AuditDate (para EventTime). Exporte estos datos a un segundo archivo CSV llamado AuditHistory.csv.
Transformación y combinación de datos: Los archivos CSV exportados deben combinarse y reorganizarse en un único registro de eventos. Utilice una herramienta de preparación de datos, como Power Query en Excel, Python o una herramienta de base de datos, para realizar los siguientes pasos:
- Cargue ServiceRequests.csv y AuditHistory.csv.
- Utilice el archivo ServiceRequests.csv para generar el evento 'Service Request Created' para cada solicitud.
- Utilice el archivo AuditHistory.csv para generar el resto de los eventos. Asigne los valores de las columnas FieldName y NewValue a los nombres de actividad requeridos. Por ejemplo, si FieldName es 'Status' y NewValue es 'Resolved', ActivityName se convierte en 'Service Request Resolved'.
- Una los eventos de auditoría transformados con los datos de las solicitudes de servicio mediante ParentLink_RecID del archivo de auditoría y RecId del archivo de solicitudes de servicio. De este modo, añadirá los atributos del caso a cada evento.
- Combine los eventos de creación y los eventos derivados de la auditoría en una única tabla.
Dé formato a la tabla combinada final con los encabezados de columna requeridos: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate y otros atributos recomendados. Asegúrese de que todas las marcas de tiempo utilicen un formato coherente.
Guarde el registro de eventos final como un único archivo CSV, listo para cargarlo.

Configuración

Objetos de negocio: Este método requiere exportar datos de dos objetos de negocio independientes: ServiceReq para los datos principales de la solicitud y FRS_data_audit_history para los datos de eventos.
Filtro de intervalo de fechas: Es fundamental aplicar un filtro de intervalo de fechas a ambas exportaciones para controlar el volumen de datos. Utilice el campo CreatedDateTime en ServiceReq y el campo AuditDate en FRS_data_audit_history. Para el análisis inicial, se recomienda un periodo de 3 a 6 meses.
Filtros clave del historial de auditoría:
- ParentObjectType debe filtrarse por 'ServiceReq' para garantizar que solo se extraigan cambios relacionados con solicitudes de servicio.
- Opcionalmente, puede filtrar FieldName para incluir únicamente los campos relevantes para su proceso, como 'Status', 'Owner', 'OwnerTeam' y 'Priority', lo que puede reducir considerablemente el tamaño de la exportación.
Requisitos previos: Se necesita una cuenta de usuario en Ivanti Service Manager con permisos para crear Saved Searches y exportar datos de los objetos de negocio ServiceReq y FRS_data_audit_history.
Consideraciones de rendimiento: La tabla FRS_data_audit_history puede ser muy grande. Exportar datos sin un filtro de fechas restrictivo puede causar problemas de rendimiento en la aplicación Ivanti y provocar un tiempo de espera agotado. Si es necesario, considere exportar los datos en lotes mensuales o trimestrales más pequeños.

a Consulta de ejemplo sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Pasos

Requisitos previos y configuración: Asegúrese de tener Python 3.6 o una versión posterior instalada en su sistema. Instale las bibliotecas necesarias, requests para realizar llamadas a la API y pandas para manipular datos, ejecutando pip install requests pandas. Solicite una clave de API al administrador de Ivanti Service Manager, con al menos permisos de lectura para los objetos de negocio ServiceReq y FRS_Audit_ServiceReq.
Configure el script: Descargue el script de Python proporcionado. Ábralo en un editor de texto o IDE y actualice las variables de marcador situadas al principio: TENANT_URL, API_KEY, START_DATE y END_DATE, según su entorno de Ivanti y el periodo de extracción deseado.
Ejecute el script: Ejecute el script desde la línea de comandos mediante python your_script_name.py. Primero, el script mostrará un mensaje que indica que se está conectando y autenticando con la API de Ivanti.
Obtenga los datos de las solicitudes de servicio: El script comienza consultando el objeto de negocio ServiceReq para obtener todas las solicitudes creadas dentro del intervalo de fechas especificado. Gestiona automáticamente la paginación de la API para recuperar la lista completa de solicitudes y muestra actualizaciones de progreso mientras obtiene cada página de datos.
Obtenga el historial de auditoría: Para cada solicitud de servicio recuperada, el script realiza una segunda consulta al objeto de negocio FRS_Audit_ServiceReq. Así obtiene el historial completo de cambios de campos de esa solicitud, un elemento esencial para crear el registro de eventos detallado.
Genere el evento 'Created': Mientras procesa cada solicitud de servicio, el script crea primero el evento 'Service Request Created'. La marca de tiempo de este evento se obtiene directamente del campo CreatedDateTime del registro de la solicitud.
Genere eventos a partir del registro de auditoría: A continuación, el script recorre los registros del historial de auditoría de cada solicitud de servicio. Analiza cada registro para identificar cambios en campos clave como Status, OwnerTeam, Owner y Priority.
Asigne los cambios a actividades: La lógica de asignación predefinida del script convierte estos cambios de campos en nombres de actividad específicos. Por ejemplo, un cambio en el campo Status de 'Active' a 'Resolved' se registra como la actividad 'Service Request Resolved'.
Construya el registro de eventos: Todos los eventos generados, tanto la creación inicial como los cambios posteriores del historial de auditoría, se recopilan en una lista estructurada. Cada evento incluye el ID de la solicitud de servicio, el nombre de la actividad, la marca de tiempo y otros atributos relevantes.
Transforme y dé formato a los datos: La lista de eventos recopilada se convierte en un DataFrame de Pandas. El script garantiza que todas las columnas coincidan con el esquema requerido por ProcessMind, incluidas ServiceRequestID, ActivityName y EventTime.
Exporte a CSV: Una vez procesadas todas las solicitudes de servicio y sus historiales, el script guarda el DataFrame final en un archivo CSV llamado ivanti_servicereq_event_log.csv, en el mismo directorio desde el que se ejecutó el script. Este archivo está listo para cargarse.

Configuración

URL del endpoint de la API: La URL base de la API REST del tenant de Ivanti Service Manager. Debe configurarse en la variable TENANT_URL del script, por ejemplo, https://your-tenant.ivanti.com.
Clave de API: Una clave válida de la API REST generada en la consola de administración de Ivanti. Esta clave debe estar asociada a un rol con permisos de lectura para los objetos de negocio ServiceReq y FRS_Audit_ServiceReq.
Intervalo de fechas: El script requiere START_DATE y END_DATE en formato 'YYYY-MM-DD'. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses, que permita controlar el volumen de datos y, al mismo tiempo, capturar suficientes variaciones del proceso.
Tamaño de página (TOP_COUNT): Esta variable del script define el número de registros que se obtienen en cada llamada a la API. El valor predeterminado es 500, un buen equilibrio entre rendimiento y uso de memoria. Puede ajustarlo según el rendimiento de su servidor de API.
Campos requeridos (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): El script especifica los campos que debe recuperar de la API para minimizar el tamaño de la carga útil. Asegúrese de incluir en estas listas todos los campos necesarios para los atributos requeridos y recomendados.

a Consulta de ejemplo python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

¿Listo para comenzar?

Descubra todo el potencial de su proceso de gestión de solicitudes de servicio con esta plantilla detallada de datos. Empiece a optimizar sus operaciones hoy mismo.

Volver a la guía de mejora Descargar Template

Empiece a optimizar hoy su gestión de solicitudes de servicio

Ponga fin a las demoras en la atención, reduzca la frustración de los usuarios y alcance una tasa de automatización del 70 %.

Iniciar la prueba gratuita

No necesita tarjeta de crédito y puede configurarlo en pocos minutos.

Su Template de datos para la gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

Exportación a CSV de búsquedas guardadas y datos de cuadrícula de Ivanti

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Ivanti

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Empiece a optimizar hoy su gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

Exportación a CSV de búsquedas guardadas y datos de cuadrícula de Ivanti

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Ivanti

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Empiece a optimizar hoy su gestión de solicitudes de servicio

Valoramos su privacidad