> 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 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

Este Template ofrece una guía completa para recopilar los datos esenciales que necesita para aplicar Process Mining a la gestión de solicitudes de servicio. Incluye los atributos clave que debe recopilar, las actividades que conviene seguir y recomendaciones prácticas para extraer esta información de su sistema. Utilice este recurso para crear un Registro de eventos sólido para el análisis.

Atributos recomendados para un análisis completo
Actividades clave para descubrir el proceso
Guía para extraer datos de su sistema de origen

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

Descargar Template

Atributos de la gestión de solicitudes de servicio

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar en detalle el proceso de gestión de solicitudes de servicio.

5 Obligatorio 9 Recomendado 7 Opcional

	Nombre	Descripción
	Hora del evento EventTime	Marca de tiempo que indica cuándo ocurrió 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 los tiempos de ciclo, de espera y de duración de las 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, fundamentales para analizar el 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 la solicitud de servicio ServiceRequestID	Identificador único de cada solicitud de servicio.
Descripción El ID de la solicitud de servicio identifica de forma única cada solicitud individual presentada por un usuario o un sistema. Es el vínculo 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. Por qué es importante Es el identificador esencial del caso que conecta todas las actividades relacionadas en una única instancia del proceso y permite analizarlo de principio a fin. Dónde obtenerlo Es la clave principal del objeto de negocio Service Request y suele encontrarse como ServiceReqNumber en la tabla ServiceReq. Ejemplos SR-0012345SR-0012346SR-0012347
	Nombre de la actividad ActivityName	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 concreto o un cambio de estado dentro del proceso de solicitud de servicio, como 'Solicitud enviada para aprobación' o 'Solicitud de servicio resuelta'. Analizar la secuencia y la frecuencia de las actividades es fundamental para comprender el flujo del proceso, detectar cuellos de botella y descubrir desviaciones del procedimiento estándar. Por qué es importante Define los pasos del mapa de procesos y permite visualizar y analizar el flujo, incluidos los retrabajos, los cuellos de botella y las desviaciones. Dónde obtenerlo Por lo general, se obtiene de los cambios de estado, las entradas del diario o las descripciones de eventos del registro de auditoría de Ivanti Service Manager. Ejemplos Solicitud de servicio creadaSolicitud aprobadaSolicitud de servicio resueltaSolicitud de servicio cerrada
	Sistema de origen SourceSystem	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 cuando se combinan datos de varios sistemas, ya que permite mantener clara su procedencia y contexto. Por qué es importante Aporta contexto esencial sobre la procedencia de los datos y garantiza que los análisis se atribuyan al sistema de origen correcto, especialmente en entornos con varios sistemas. Dónde obtenerlo Por lo general, es un valor estático que se añade durante la extracción de datos para indicar el origen del conjunto de datos. Ejemplos Ivanti Service Manager
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la actualización más reciente de los datos del 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. Informa sobre la actualidad de los datos analizados y permite saber qué periodo abarca el análisis y cuándo se espera la próxima actualización. Por qué es importante Informa 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 añade al conjunto de datos durante la extracción. Ejemplos 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Agente asignado AssignedAgent	La persona o el agente asignado a la solicitud de servicio.
Descripción El agente asignado es la persona responsable de gestionar la solicitud de servicio. Este atributo permite analizar el trabajo a nivel individual, lo que resulta útil para gestionar el rendimiento, equilibrar la carga de trabajo e identificar necesidades de formación. Registrar los cambios de agente es fundamental 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 y el rendimiento individuales, así como los patrones de reasignación, que pueden revelar problemas de formación, competencias o asignación inicial. Dónde obtenerlo Suele encontrarse en un campo como «Owner» del objeto Service Request. Puede cambiar con cada reasignación, por lo que conviene registrarlo en el Registro de eventos. Ejemplos Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Equipo asignado AssignedTeam	El equipo o grupo de soporte asignado en ese momento para atender la solicitud de servicio.
Descripción Este atributo identifica al equipo responsable de atender la solicitud de servicio en un momento determinado. Analizar los traspasos entre equipos, el tiempo que cada uno dedica a las solicitudes y el volumen que gestiona 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 permite crear Dashboards sobre el cumplimiento de los SLA y la carga de trabajo de los agentes. Por qué es importante Permite hacer un seguimiento de las responsabilidades y los traspasos, y analizar los retrasos entre equipos, el equilibrio de la carga de trabajo y qué equipos generan cuellos de botella en el 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 Recursos HumanosGestión de instalaciones
	Estado de la solicitud de servicio ServiceRequestStatus	Estado de la solicitud de servicio en el momento del evento.
Descripción Este atributo registra el estado de la solicitud de servicio, por ejemplo, «Registrada», «En curso», «Pendiente», «Resuelta» o «Cerrada». Los cambios de estado suelen definir las actividades del Registro de eventos. Analizar el tiempo que las solicitudes permanecen en cada estado puede revelar cuellos de botella, por ejemplo, si pasan demasiado tiempo en estado «Pendiente». Por qué es importante Ofrece una instantánea del estado de la solicitud en cada momento. Esto es esencial para calcular cuánto tiempo permanece en estados específicos e identificar interrupciones en el proceso. Dónde obtenerlo Campo estándar del objeto Service Request, normalmente llamado «Status». Ejemplos RegistradaActivoEn espera del clienteAtendidaCerrada
	Estado del SLA SLAStatus	Indica si la solicitud de servicio se resolvió antes de la fecha límite del SLA.
Descripción Este atributo derivado indica si cada solicitud de servicio cumplió el SLA o lo incumplió, según la hora de resolución y la fecha límite correspondiente. Es la base del Dashboard «Rendimiento del cumplimiento de los 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 las personas usuarias. 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	Marca de tiempo límite para 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 depender de 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 valor de referencia para medir el rendimiento real. Permite calcular directamente las tasas de cumplimiento de los SLA e identificar las solicitudes que podrían incumplirlos. 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	Marca de tiempo que indica cuándo se completó una actividad.
Descripción La hora de finalización del evento marca cuándo se completa una actividad. El tiempo transcurrido entre la hora del evento (inicio) y la hora de finalización del evento corresponde al tiempo de procesamiento de esa actividad. Este dato es fundamental para identificar qué pasos del proceso consumen más tiempo y detectar ineficiencias y oportunidades de mejora. Por qué es importante Permite calcular la duración de cada actividad, algo esencial para identificar cuellos de botella en el proceso y tareas que se prolongan demasiado. Dónde obtenerlo Es posible que no exista como campo independiente. A menudo, corresponde a la hora de inicio de la actividad siguiente en la secuencia del mismo caso. Ejemplos 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Marca de tiempo de resolución ResolutionDateTime	Fecha y hora en que se resolvió oficialmente la solicitud de servicio.
Descripción Este atributo del caso registra la marca de tiempo final en que se prestó el servicio o se solucionó el problema, antes del cierre formal de la solicitud. Es el punto de referencia principal para calcular el tiempo de ciclo integral de una solicitud de servicio y un componente clave para medir la eficiencia general del proceso y el cumplimiento de los SLA. Por qué es importante Define el punto final para calcular el tiempo de ciclo del proceso principal, un KPI clave de la eficiencia en la prestación del servicio. Dónde obtenerlo Campo específico de marca de tiempo del objeto Service Request, a menudo llamado «ResolvedDateTime» o similar. Ejemplos 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Prioridad Priority	Nivel de prioridad asignado a la solicitud de servicio.
Descripción La prioridad indica la urgencia de una solicitud de servicio y suele expresarse en una escala como «Baja», «Media», «Alta» y «Crítica». Este atributo es fundamental para evaluar si el proceso agiliza eficazmente las solicitudes de alta prioridad. El análisis suele comparar los tiempos de ciclo y el cumplimiento de los SLA entre los distintos niveles de prioridad para comprobar 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 antes que las de baja prioridad. Dónde obtenerlo Campo estándar del objeto Service Request, normalmente llamado «Priority». Ejemplos 1 - Crítica2 - Alta3 - Media4 - Baja
	Tipo de solicitud de servicio ServiceRequestType	Clasificación o categoría de la solicitud de servicio.
Descripción Este atributo clasifica la solicitud de servicio, por ejemplo, como «Solicitud de hardware», «Instalación de software» o «Restablecimiento de contraseña». Es una dimensión clave para comparar el rendimiento del proceso, los tiempos de ciclo y el cumplimiento de los 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 tienden más a sufrir retrasos, retrabajo o incumplimientos de los SLA. Dónde obtenerlo Probablemente sea un campo del objeto de negocio Service Request, con nombres como «Service» o «Category». Consulte la documentación de Ivanti Service Manager para conocer los nombres concretos de los campos, como «SvcReqTmplLink_Category». Ejemplos Nueva solicitud de hardwareAcceso a softwareModificación de cuentaConsulta de información
	Canal Channel	Método o canal por el que se presentó 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, por correo electrónico o teléfono, o automáticamente desde otro sistema. Analizar el volumen de solicitudes y los tiempos de resolución por canal permite saber cuáles son más eficientes y cuáles podrían requerir mejoras en el proceso o formación para las personas usuarias. Por qué es importante Ayuda a comprender el comportamiento de las personas usuarias y la eficiencia de cada canal, lo que permite tomar decisiones sobre la estrategia de prestación del servicio y las oportunidades de automatización. Dónde obtenerlo Suele almacenarse en un campo como «Source» o «CreatedBy» del objeto Service Request. Ejemplos AutoservicioCorreo electrónicoTeléfonoEntrada directa
	Categoría de resolución ResolutionCategory	Clasificación de la solució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. Suele ser una clasificación jerárquica, por ejemplo, categoría y subcategoría, que facilita el análisis de causas raíz y la elaboración de informes de tendencias. Puede revelar problemas recurrentes o acciones de atención habituales, que sirven para mejorar los servicios o crear artículos para la base de conocimientos. Por qué es importante Ofrece información sobre la naturaleza de las resoluciones y ayuda a identificar problemas frecuentes, oportunidades para mejorar el servicio y posibles casos de automatización. Dónde obtenerlo Suele almacenarse en campos de clasificación que se completan al resolver la solicitud, como «ResolutionCategory» o un campo personalizado para el código de cierre. Ejemplos Se requiere formación de la persona usuariaSoftware implementadoHardware reparadoAcceso concedido
	Departamento de quien solicita RequestorDepartment	Departamento de la organización al que pertenece la persona que presentó la solicitud de servicio.
Descripción Este atributo identifica el departamento de la persona o el sistema que inició la solicitud de servicio, por ejemplo, «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 detectar si algunos departamentos tienen tiempos de resolución más largos o presentan un mayor volumen de solicitudes. Por qué es importante Permite analizar el consumo y la calidad del servicio por unidad de negocio, e identificar problemas o tendencias específicos de cada departamento. Dónde obtenerlo Esta información suele obtenerse del perfil de usuario de quien realiza la solicitud, vinculado a la solicitud de servicio. El campo podría llamarse «Department» en el objeto Profile.Employee. Ejemplos FinanzasVentasMarketingTecnología de la información
	Es retrabajo IsRework	Indicador booleano que señala si la solicitud de servicio incluyó actividades de retrabajo.
Descripción Este indicador calculado se establece en true si la solicitud de servicio presenta señales de retrabajo, como volver a abrirse después de su resolución o repetir ciertas actividades en un ciclo. Simplifica el cálculo del KPI «Tasa de retrabajo de solicitudes de servicio» y permite filtrar los casos de proceso ineficientes en Dashboards como «Flujos de retrabajo y reasignación». Por qué es importante Facilita la identificación y cuantificación de las solicitudes que requieren trabajo adicional no previsto, y pone de manifiesto problemas de calidad y eficiencia. Dónde obtenerlo Se obtiene a partir 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	Nombre del proveedor externo que participó en la resolución de la solicitud.
Descripción Este atributo identifica al proveedor externo que intervino para ayudar a resolver o completar una solicitud de servicio. Es esencial para el Dashboard «Duración de la actividad de proveedores externos», ya que permite medir y comparar el rendimiento de distintos proveedores. El seguimiento de este dato ayuda a gestionar las relaciones con 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 facilita la gestión de proveedores. Dónde obtenerlo Podría ser un campo de un objeto Task 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	Número total de veces que se asignó o reasignó una solicitud de servicio.
Descripción Esta métrica calculada cuenta las actividades relacionadas con asignaciones, como «Assigned to Team» y «Assigned to Agent», de cada solicitud de servicio. Un número elevado de reasignaciones, conocido a menudo como «ping-pong de tickets», indica problemas de eficiencia en el enrutamiento, falta de resolución en el primer contacto o responsabilidades poco claras entre equipos. Este atributo es esencial para el KPI «Promedio de reasignaciones por solicitud». Por qué es importante Cuantifica los traspasos ineficientes y los problemas de enrutamiento. Un número elevado suele indicar tiempos de resolución prolongados y frustración de las personas usuarias. 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	Número de veces que se ha vuelto a abrir 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 «Activo». Un número elevado de reaperturas suele indicar una resolución deficiente desde el primer intento, soluciones incompletas o problemas recurrentes. Este dato permite calcular 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 las resoluciones. Un número elevado sugiere que la solución inicial no fue eficaz. Dónde obtenerlo Suele ser un campo contador del objeto Service Request que una regla de negocio incrementa cuando se produce el cambio de estado correspondiente. Podría llamarse «ReopenCounter». Ejemplos 0123

Obligatorio Recomendado Opcional

Actividades de gestión de solicitudes de servicio

Estos son los pasos y los hitos esenciales que debe registrar en el 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 concreto se hace cargo de la solicitud de servicio. Por lo general, esta actividad se infiere cuando el campo 'Owner', que identifica al agente, se completa o se actualiza por primera vez.
Por qué es importante Este evento marca el final de la espera inicial o del tiempo en cola. Medir el tiempo transcurrido hasta esta actividad ayuda a detectar problemas de asignación de recursos y aporta información al Dashboard de carga de trabajo de los agentes. Dónde obtenerlo Se infiere a partir de la asignación o el cambio del campo 'Owner' en el registro de Service Request, según el historial de auditoría. Capturar 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 de 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 que la gestione. Esto se registra al detectar que se completa o cambia el campo 'OwnerTeam' del registro de Service Request.
Por qué es importante Este evento es fundamental para analizar el rendimiento de cada equipo, la distribución de la carga de trabajo y los tiempos de traspaso entre equipos. Ayuda a identificar qué equipos generan cuellos de botella en el proceso. Dónde obtenerlo Se registra mediante los cambios en el campo 'OwnerTeam' del historial de auditoría o el diario de la solicitud de servicio. Capturar Un evento de actualización del campo 'OwnerTeam', que suele quedar registrado en el historial de auditoría. Tipo de evento explicit
	Solicitud de servicio cerrada	La solicitud de servicio se ha cerrado oficialmente y no admite más acciones. Esto suele ocurrir automáticamente después de un periodo determinado en el estado 'Resolved' y marca el final del ciclo de vida.
Por qué es importante Esta actividad marca el final definitivo del proceso. El tiempo transcurrido entre 'Resolved' y 'Closed' puede revelar demoras en la confirmación o en los procesos automatizados del sistema. Dónde obtenerlo Se infiere a partir de un cambio del campo 'Status' del registro de Service Request a 'Closed', junto con la marca de tiempo correspondiente. Capturar Se detecta en el historial de auditoría cuando el campo 'Status' se actualiza a 'Closed'. Tipo de evento inferred
	Solicitud de servicio creada	Esta actividad marca el inicio del ciclo de vida de una solicitud de servicio, cuando se presenta y registra formalmente una nueva solicitud en Ivanti. El evento se registra al crear un nuevo registro en el objeto de negocio Service Request, que genera un ID único para la solicitud.
Por qué es importante Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde este momento hasta la resolución es fundamental para medir el tiempo de ciclo total y la eficiencia del proceso. Dónde obtenerlo Se obtiene de la marca de tiempo de creación del registro de Service Request (por ejemplo, del campo CreatedDateTime en el objeto de negocio ServiceReq). Capturar 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 hito principal se registra cuando el estado cambia a 'Resolved', lo que suele detener el contador del SLA.
Por qué es importante Este es un punto final fundamental para medir el tiempo de resolución y el cumplimiento del SLA. El tiempo transcurrido desde la creación hasta esta actividad es un KPI clave del rendimiento del proceso. Dónde obtenerlo Se infiere a partir de un cambio del campo 'Status' del registro de Service Request a 'Resolved', junto con la marca de tiempo correspondiente. Capturar Se detecta en el historial de auditoría cuando el campo 'Status' se actualiza a 'Resolved'. Tipo de evento inferred
	Información proporcionada por el usuario	Quien realizó la solicitud ha proporcionado la información necesaria y el agente puede reanudar el trabajo. Esto se registra cuando la solicitud deja el estado 'Waiting for Customer' y vuelve a uno activo.
Por qué es importante Este evento cierra el ciclo de las solicitudes de información. El tiempo transcurrido entre la solicitud y la recepción de la información es un factor importante en las demoras y los ciclos de retrabajo del proceso. Dónde obtenerlo Se infiere cuando el campo 'Status' del registro de Service Request cambia de 'Waiting for Customer' a un estado activo, como 'Active' o 'In Progress'. Capturar Se detecta cuando el estado cambia de uno definido como 'waiting on user' a uno activo. Tipo de evento inferred
	Información solicitada al usuario	El agente asignado necesita más información de quien realizó la solicitud para poder atenderla. Esto se registra cuando el estado de la solicitud cambia a uno como 'Waiting for Customer'.
Por qué es importante Esta actividad pone de manifiesto las demoras causadas por la falta de información inicial. 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 detectar oportunidades de mejora del proceso. Dónde obtenerlo Se infiere a partir de un cambio de estado del registro de Service Request a uno como 'Waiting for Customer' o 'Pending'. Capturar Se detecta cuando el campo 'Status' cambia a un estado definido 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. Este evento se obtiene del registro o historial de auditoría que recoge los cambios en los campos.
Por qué es importante Hacer un seguimiento de los cambios de prioridad es fundamental para el resumen de la eficacia de la priorización. Permite determinar si las escalaciones se gestionan correctamente y si la prioridad inicial es adecuada. Dónde obtenerlo Este evento explícito se obtiene del historial de auditoría del registro de Service Request, donde se registran los cambios en el campo 'Priority'. Capturar Un evento de actualización del campo 'Priority' registrado en el historial de auditoría del sistema. Tipo de evento explicit
	Proveedor externo involucrado	La atención de la solicitud de servicio se ha transferido a un proveedor externo o a un tercero. Por lo general, esto se registra cuando el estado cambia a 'Waiting for 3rd Party' o a uno similar.
Por qué es importante Esta actividad es esencial para medir el rendimiento del proveedor y su impacto en el tiempo de ciclo total. Permite analizar las demoras relacionadas con proveedores y aporta información al Dashboard de duración de las actividades de proveedores externos. Dónde obtenerlo Se infiere a partir de un cambio de estado del registro de Service Request a uno como 'Waiting for 3rd Party' o 'Pending Vendor'. Capturar Se detecta cuando el campo 'Status' cambia a un estado definido como 'waiting on vendor'. Tipo de evento inferred
	Solicitud aprobada	La solicitud de servicio ha recibido todas las aprobaciones necesarias y ya puede pasar a la fase de atención. Este evento se registra cuando el flujo de trabajo 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 de la atención. Permite medir la eficiencia del 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 registrarse como un evento explícito en el objeto de negocio FRS_Approval. Capturar Un cambio en el campo 'Status' del registro de Service Request, de un estado de aprobación a uno activo. Tipo de evento inferred
	Solicitud de servicio atendida	El agente o el sistema ha completado todas las tareas necesarias para atender la solicitud de servicio. Esto se registra cuando el estado cambia a 'Fulfilled', lo que suele ocurrir antes del estado final 'Resolved'.
Por qué es importante Este hito marca la finalización del trabajo técnico o del procedimiento. Es un punto clave para medir el tiempo de gestión activa antes de la confirmación final y el cierre. Dónde obtenerlo Se infiere a partir de un cambio del campo 'Status' del registro de Service Request a 'Fulfilled'. Capturar Un cambio del campo 'Status' a 'Fulfilled', detectado en el historial del registro. Tipo de evento inferred
	Solicitud de servicio cancelada	El usuario o un agente ha cancelado la solicitud de servicio antes de que se resolviera. Este estado final alternativo se registra cuando el estado cambia a 'Cancelled' o 'Withdrawn'.
Por qué es importante Esto representa una finalización no habitual del proceso. Analizar los motivos de las cancelaciones 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 del campo 'Status' del registro de Service Request a 'Cancelled'. Capturar Se detecta en el historial de auditoría cuando el campo 'Status' se actualiza a 'Cancelled'. Tipo de evento inferred
	Solicitud de servicio reabierta	Una solicitud de servicio que ya se había resuelto se ha reactivado porque el problema persiste o la solución no fue satisfactoria. Esto se registra cuando el estado cambia de 'Resolved' a uno activo, como 'Active' o 'Assigned'.
Por qué es importante Esta actividad indica directamente que hubo retrabajo y que la resolución no fue satisfactoria en el primer intento. Analizar las reaperturas ayuda a detectar debilidades del proceso y a mejorar el KPI de tasa de retrabajo de solicitudes de servicio. Dónde obtenerlo Se infiere del historial de auditoría cuando el campo 'Status' cambia de 'Resolved' o 'Closed' a un estado activo. Capturar Un cambio de estado de uno final ('Resolved', 'Closed') a uno 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 atenderla. Por lo general, se infiere cuando el estado de la solicitud cambia a 'Submitted' o 'Pending Approval', lo que suele activar un flujo de trabajo de aprobación.
Por qué es importante El seguimiento de esta actividad ayuda a detectar demoras en la fase de aprobación. Las esperas prolongadas pueden convertirse en un cuello de botella importante y afectar los tiempos de resolución y la satisfacción de los usuarios. Dónde obtenerlo Se infiere a partir de un cambio de estado del 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. Capturar 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 las solicitudes de servicio y a su historial de auditoría.
Vaya al espacio de trabajo de solicitudes de servicio desde el menú de navegación principal.
Para este proceso, debe exportar dos conjuntos de datos por separado y combinarlos externamente. El primero incluye el evento de creación y los atributos principales; el segundo, el historial detallado de cambios.
Primera exportación (eventos de creación): Cree una búsqueda guardada en el objeto de negocio ServiceReq. Añada un filtro en CreatedDateTime para seleccionar las solicitudes creadas durante el período que desea analizar, 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 (Responsable), Priority, Status (Estado), ResolutionDateTime y TargetDateTime (para SLADeadline).
Ejecute la búsqueda y use la función de exportación de la cuadrícula, que suele aparecer como un icono de disco o 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 otra búsqueda guardada, esta vez en el objeto de negocio FRS_data_audit_history, que registra los cambios en los campos.
Filtre la búsqueda para incluir solo los cambios relacionados con las solicitudes de servicio. Añada un filtro para que ParentObjectType sea igual a 'ServiceReq'. Añada también un filtro en AuditDate para usar el mismo período de análisis que antes.
Configure las columnas de la búsqueda de auditoría para incluir ParentLink_RecID (para vincular los datos 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: Combine y reorganice los archivos CSV exportados para crear un único Registro de eventos. Utilice una herramienta de preparación de datos, como Power Query en Excel, Python o una herramienta de bases de datos, y siga estos pasos:
- Cargue los archivos ServiceRequests.csv y AuditHistory.csv.
- Use el archivo ServiceRequests.csv para generar el evento 'Service Request Created' para cada solicitud.
- Use el archivo AuditHistory.csv para generar los demás eventos. Asigne los valores de las columnas FieldName y NewValue a los nombres de actividad necesarios. Por ejemplo, si FieldName es 'Status' y NewValue es 'Resolved', el valor de ActivityName será '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. Así, cada evento incluirá los atributos del caso.
- Combine los eventos de creación y los derivados de la auditoría en una sola tabla.
Dé formato a la tabla final combinada con los encabezados de columna necesarios: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate y los demás atributos recomendados. Asegúrese de que todas las marcas de tiempo tengan un formato uniforme.
Guarde el Registro de eventos final en un único archivo CSV, listo para cargar.

Configuración

Objetos de negocio: Este método requiere exportar datos de dos objetos de negocio distintos: ServiceReq, que contiene los datos principales de las solicitudes, y FRS_data_audit_history, que contiene los datos de los eventos.
Filtro por período: Es fundamental aplicar un filtro de fechas a ambas exportaciones para controlar el volumen de datos. Use el campo CreatedDateTime de ServiceReq y el campo AuditDate de FRS_data_audit_history. Para el análisis inicial, se recomienda un período de entre 3 y 6 meses.
Filtros clave para el historial de auditoría:
- Filtre ParentObjectType por 'ServiceReq' para extraer únicamente los cambios relacionados con las solicitudes de servicio.
- Si lo desea, filtre FieldName para incluir solo los campos relevantes para su proceso, como 'Status' (Estado), 'Owner' (Responsable), 'OwnerTeam' y 'Priority'. Esto puede reducir considerablemente el tamaño de la exportación.
Requisitos previos: Necesita una cuenta de usuario de Ivanti Service Manager con permisos para crear búsquedas guardadas 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 afectar el rendimiento de la aplicación Ivanti y provocar que se agote el tiempo de espera. Si es necesario, exporte los datos en lotes mensuales o trimestrales más pequeños.

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 instalado 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 al administrador de Ivanti Service Manager una clave de API 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 de posición de la parte superior: TENANT_URL, API_KEY, START_DATE y END_DATE, según su entorno de Ivanti y el período de extracción que desee analizar.
Ejecute el script: Ejecútelo desde la línea de comandos con python your_script_name.py. Primero, el script mostrará un mensaje para indicar que se está conectando y autenticando con la API de Ivanti.
Obtenga los datos de las solicitudes de servicio: El script consulta el objeto de negocio ServiceReq para obtener todas las solicitudes creadas dentro del período especificado. Gestiona automáticamente la paginación de la API para recuperar la lista completa de solicitudes y muestra el progreso a medida que obtiene cada página de datos.
Obtenga el historial de auditoría: Para cada solicitud de servicio recuperada, el script realiza una consulta secundaria al objeto de negocio FRS_Audit_ServiceReq. Así obtiene el historial completo de cambios en los campos de esa solicitud, necesario para crear el registro de eventos detallado.
Genere el evento «Creación de solicitud»: Al procesar cada solicitud de servicio, el script crea primero el evento «Solicitud de servicio creada». La marca de tiempo se obtiene directamente del campo CreatedDateTime del registro de la solicitud.
Genere eventos a partir del historial de auditoría: A continuación, el script recorre los registros de auditoría de cada solicitud de servicio. Analiza cada registro para identificar cambios en campos clave como Estado, OwnerTeam, Responsable y Priority.
Asigne los cambios a actividades: La lógica de asignación predefinida del script convierte estos cambios en campos en nombres de actividad específicos. Por ejemplo, un cambio en el campo Estado de «Activo» a «Resuelto» se registra como la actividad «Solicitud de servicio resuelta».
Construya el registro de eventos: Todos los eventos generados, tanto el de creación inicial como los cambios posteriores del historial de auditoría, se reúnen 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 pertinentes.
Transforme y dé formato a los datos: La lista de eventos recopilados se convierte en un DataFrame de Pandas. El script verifica 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. El archivo está listo para cargarse.

Configuración

URL del endpoint de la API: La URL base de la API REST del inquilino de Ivanti Service Manager. Debe asignarse a 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. Debe estar asociada a un rol con permisos de lectura para los objetos de negocio ServiceReq y FRS_Audit_ServiceReq.
Período: El script requiere las fechas START_DATE y END_DATE con el formato 'YYYY-MM-DD'. Para el análisis inicial, se recomienda un período de entre 3 y 6 meses: permite mantener un volumen de datos manejable y, a la vez, capturar suficientes variantes del proceso.
Tamaño de página (TOP_COUNT): Esta variable del script define cuántos registros se recuperan 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 necesarios (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): El script especifica los campos que debe recuperar de la API para reducir el tamaño de los datos transferidos. Compruebe que estas listas incluyan todos los campos necesarios para los atributos obligatorios y recomendados.

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 empezar?

Aproveche al máximo el proceso de gestión de solicitudes de servicio con este Template detallado de datos. Empiece hoy mismo a optimizar sus operaciones.

Volver a la guía de mejora

Descargar Template

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

Reduzca los retrasos en la atención, la frustración de los usuarios y alcance una tasa de automatización del 70 %.

Comience la prueba gratuita

No se requiere tarjeta de crédito. La configuración toma solo unos 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 gestión de solicitudes de servicio

Guías de extracción

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

Pasos

Configuración

Consulta de ejemplo sql

Script de Python con la API REST de Ivanti

Pasos

Configuración

Consulta de ejemplo python

¿Listo para empezar?

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