> Mejora continua de procesos > Gestión de solicitudes de servicio > ServiceNow > Template de datos

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

ServiceNow

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 (3)

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

Este completo Template de datos está diseñado para simplificar su recorrido de Process Mining en la gestión de solicitudes de servicio. Proporciona orientación clara sobre los atributos esenciales que debe recopilar, las actividades críticas que debe supervisar y las instrucciones prácticas de extracción específicas para ServiceNow. El uso de este Template garantiza que capture todos los datos necesarios para realizar un análisis preciso y optimizar el proceso de forma eficaz.

Atributos recomendados para recopilar
Actividades clave que debe supervisar para descubrir el proceso
Instrucciones paso a paso para extraer los datos

¿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 6 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre del evento o la tarea específicos que tuvieron lugar durante el ciclo de vida de la solicitud de servicio.
Descripción El atributo Activity registra el nombre de cada paso o cambio de estado del proceso de solicitud de servicio. Puede incluir eventos como «Request Created», «Request Approved», «Assigned to Agent» o «Request Closed». El análisis de estas actividades permite visualizar el flujo del proceso, identificar las rutas habituales y detectar desviaciones respecto al procedimiento estándar. Es la base para comprender lo que ocurre realmente durante la ejecución de las solicitudes. Por qué es importante Es un atributo obligatorio que define los pasos del mapa de procesos. Es fundamental para todo análisis de procesos, incluido el descubrimiento de cuellos de botella, ciclos de retrabajo y problemas de cumplimiento. Dónde obtenerlo Se deriva de los cambios en los campos «State» o «Stage» de tablas como «sc_request» o «sc_req_item», o del registro de auditoría (sys_audit). Ejemplos Solicitud de servicio creadaSolicitud asignada a un grupoSolicitud de servicio resueltaInformación solicitada al usuario
	Hora de inicio EventTime	La marca de tiempo que indica cuándo comenzó una actividad o un evento.
Descripción Este atributo captura la fecha y hora exactas en que tuvo lugar cada actividad del proceso de solicitud de servicio. Proporciona la secuencia cronológica de eventos necesaria para crear el mapa de procesos y realizar cualquier análisis basado en el tiempo. Las marcas de tiempo precisas son fundamentales para calcular los tiempos de ciclo, los tiempos de espera y las duraciones de procesamiento. Estos datos permiten identificar cuellos de botella, incumplimientos de los SLA y tendencias de rendimiento a lo largo del tiempo. Por qué es importante Esta marca de tiempo es obligatoria para ordenar correctamente los eventos. Es la base de todos los análisis de rendimiento y duración, incluido el tiempo de ciclo y la identificación de cuellos de botella. Dónde obtenerlo Normalmente se encuentra en los campos «sys_updated_on» o «sys_created_on» de las tablas de ServiceNow pertinentes, como sc_request y sc_task, o en el registro de auditoría (sys_audit). Ejemplos 2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
	ID de la solicitud de servicio ServiceRequestID	El identificador único de cada registro de solicitud de servicio.
Descripción El Service Request ID es la clave principal que identifica de forma única cada solicitud de servicio enviada por un usuario o un sistema. Actúa como el hilo central que conecta todos los eventos posteriores, desde el registro inicial hasta el cierre definitivo. En process mining, este ID es esencial para reconstruir el recorrido completo de cada solicitud y analizar su ciclo de vida en detalle. Por qué es importante Este es el Case ID obligatorio. Conecta todas las actividades relacionadas en una única instancia del proceso y permite analizar los flujos, las variaciones y los tiempos de ciclo. Dónde obtenerlo Tabla ServiceNow Request [sc_request], campo «number». Ejemplos REQ0010001REQ0010025REQ0010112
	Sistema de origen SourceSystem	El sistema del que proceden los datos.
Descripción Este atributo identifica el sistema de origen de los datos, que en este caso es ServiceNow. Resulta útil en entornos donde se combinan datos de varios sistemas para obtener una visión integral del proceso. En un análisis de una única fuente, este atributo aporta contexto importante y ayuda en la gobernanza y la gestión de datos. Garantiza que cualquier usuario comprenda el origen de los datos que está analizando. Por qué es importante Proporciona metadatos esenciales para la gobernanza, la trazabilidad y el contexto de los datos, especialmente al combinar datos de varios sistemas empresariales. Dónde obtenerlo Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos. Ejemplos ServiceNow
	Última actualización de datos LastDataUpdate	La marca de tiempo de la actualización o extracción de datos más reciente.
Descripción Este atributo indica la fecha y hora en que los datos se extrajeron por última vez del sistema de origen y se cargaron en la herramienta de process mining. Aporta transparencia sobre la actualidad de los datos analizados. Los analistas utilizan esta información para saber si están consultando los datos más recientes, algo fundamental para la supervisión operativa y la toma de decisiones en tiempo real. También ayuda a establecer expectativas sobre la actualidad de los resultados. Por qué es importante Garantiza que los usuarios conozcan la actualidad de los datos, algo esencial para confiar en el análisis y tomar decisiones oportunas basadas en datos. Dónde obtenerlo Es un campo de metadatos que se añade durante la ingesta de datos y refleja la marca de tiempo de finalización del trabajo de ETL. Ejemplos 2023-10-27T04:00:00Z
	Asignado a AssignedTo	La persona usuaria responsable de trabajar en la solicitud de servicio en un momento determinado.
Descripción Este atributo identifica al agente o técnico específico asignado a la solicitud de servicio. Cambia cuando la solicitud se transfiere entre distintas personas. Analizar el campo «Assigned To» es fundamental para comprender la distribución de la carga de trabajo, el rendimiento individual y el impacto de las transferencias en los tiempos de resolución. Ayuda a responder preguntas sobre la utilización de los recursos e identifica oportunidades de formación o de aclaración del proceso para reducir las reasignaciones. Por qué es importante Permite analizar la carga de trabajo, el rendimiento y las transferencias de los agentes. Es esencial para gestionar los recursos e identificar cuellos de botella relacionados con personas concretas. Dónde obtenerlo Tablas ServiceNow Request Item [sc_req_item] o Catalog Task [sc_task], campo «assigned_to». Ejemplos Beth AnglinDavid LooHoward Johnson
	Categoría Category	La clasificación principal de la solicitud de servicio, como Hardware o Software.
Descripción Category proporciona una clasificación de alto nivel de la solicitud de servicio. Normalmente se utiliza para dirigir la solicitud al equipo adecuado y elaborar informes sobre los tipos de solicitudes enviadas. En process mining, Category es una herramienta eficaz para filtrar y analizar dimensiones. Permite a los analistas comparar los flujos de proceso, los tiempos de ciclo y las tasas de automatización de distintos tipos de solicitudes, y descubrir variaciones que podrían no ser visibles a nivel agregado. Por ejemplo, el proceso de una solicitud de «Hardware» puede ser fundamentalmente distinto del de una solicitud de «Software». Por qué es importante Permite segmentar y comparar eficazmente los procesos de distintos tipos de servicio, lo que ayuda a identificar problemas y oportunidades de mejora específicos de cada categoría. Dónde obtenerlo Tabla ServiceNow Request Item [sc_req_item], normalmente a través de la categoría del Catalog Item asociado [sc_cat_item]. Ejemplos HardwareSoftwareSolicitud de accesoRed
	Estado State	El estado operativo actual de la solicitud de servicio.
Descripción El atributo State indica la etapa actual de la solicitud de servicio en su ciclo de vida, como «Open», «Work in Progress», «Pending» o «Closed». Los cambios en este campo suelen utilizarse para generar las actividades del mapa de procesos. Analizar el estado es fundamental para comprender cuánto tiempo pasan las solicitudes en estados concretos, especialmente en estados de espera o pendientes. Ayuda a identificar colas y retrasos, como el tiempo en «Awaiting User Information», una fuente habitual de ciclos prolongados. Por qué es importante Proporciona información sobre el estado de la solicitud en cualquier momento, lo que permite analizar los tiempos de espera, las colas y la duración de etapas concretas del proceso. Dónde obtenerlo Tablas ServiceNow Request [sc_request] o Request Item [sc_req_item], campo «state» o «stage». Ejemplos AbiertoTrabajo en cursoA la espera de información de la persona usuariaCerrado, completado
	Grupo de asignación AssignmentGroup	El equipo o grupo responsable de gestionar la solicitud de servicio.
Descripción El grupo de asignación representa al equipo, como «Service Desk», «Network Operations» o «Database Administration», responsable de una solicitud de servicio en una etapa determinada. Es un atributo clave para analizar el flujo del proceso entre distintas áreas funcionales. Al realizar el seguimiento de los cambios en el grupo de asignación, las organizaciones pueden visualizar las transferencias entre equipos, medir los tiempos de espera en la cola de cada grupo e identificar dependencias o retrasos entre equipos. Esto es fundamental para optimizar la colaboración interfuncional. Por qué es importante Registra la distribución del trabajo entre equipos, destaca las transferencias entre ellos y ayuda a identificar cuellos de botella o problemas de rendimiento específicos de cada equipo. Dónde obtenerlo Tablas ServiceNow Request Item [sc_req_item] o Catalog Task [sc_task], campo «assignment_group». Ejemplos Mesa de servicioSoporte de TI L2Aprovisionamiento de hardware
	Prioridad Priority	El nivel de prioridad de la solicitud de servicio, que influye en su urgencia.
Descripción La prioridad es una clasificación que determina la importancia y la urgencia relativas de una solicitud de servicio. A menudo se establece combinando el impacto y la urgencia, y se utiliza para orientar a los agentes sobre qué solicitudes deben atender primero. Analizar los datos por prioridad es fundamental para comprobar si las solicitudes de alta prioridad se procesan más rápido que las de baja prioridad. Permite filtrar los Dashboard para verificar si se cumplen los SLA de las solicitudes críticas y ayuda a determinar si el sistema de priorización es eficaz. Por qué es importante Permite segmentar las solicitudes para comprobar que los elementos de alta prioridad se procesen más rápido. Es clave para el análisis de los SLA y la asignación de recursos. Dónde obtenerlo Tablas ServiceNow Request [sc_request] o Request Item [sc_req_item], campo «priority». Ejemplos 1 - Crítica2 - Alta3 - Moderada4 - Baja
	SLA cumplido MadeSLA	Una marca booleana que indica si la solicitud de servicio se resolvió dentro de su acuerdo de nivel de servicio.
Descripción Este atributo indica si la solicitud de servicio cumplió el acuerdo de nivel de servicio (SLA) definido para el tiempo de resolución. Es una métrica de resultado fundamental que mide directamente el rendimiento del servicio frente a los compromisos adquiridos. Analizar esta marca ayuda a cuantificar el KPI de tasa de cumplimiento de los SLA. Puede utilizarse como dimensión para comparar las rutas de proceso de las solicitudes que cumplen los SLA con las de las solicitudes que los incumplen, y revelar patrones o actividades habituales que contribuyen a los incumplimientos. Esto es esencial para supervisar los riesgos de forma proactiva y mejorar continuamente el servicio. Por qué es importante Mide directamente el rendimiento frente a los compromisos de servicio y permite analizar las causas raíz de los incumplimientos de los SLA al comparar los casos conformes y no conformes. Dónde obtenerlo Tabla ServiceNow Task SLA [task_sla], campo «has_breached». El valor debe invertirse, por ejemplo, MadeSLA = NOT has_breached. Ejemplos truefalse
	Abierto por OpenedBy	Persona que envió inicialmente la solicitud de servicio.
Descripción Este atributo identifica al usuario que creó la solicitud de servicio. Aunque a menudo coincide con la persona afectada por la solicitud, también puede ser un gerente, un delegado o un sistema automatizado. Analizar las solicitudes por el usuario que las abrió o por su departamento ayuda a identificar patrones, como un grupo específico de usuarios que envía con frecuencia solicitudes complejas o problemáticas. Esta información puede orientar la formación específica o poner de manifiesto la necesidad de mejorar los artículos de la base de conocimientos para fomentar el autoservicio. Por qué es importante Ayuda a analizar los patrones de las solicitudes por usuario, departamento o función, lo que puede orientar las iniciativas de formación y las mejoras específicas del proceso. Dónde obtenerlo Tabla Request [sc_request] de ServiceNow, campo 'opened_by'. Ejemplos Abel TuterFred LuddyDon Goodliffe
	Canal ContactType	El método que utiliza quien realiza la solicitud para enviar la solicitud de servicio.
Descripción El tipo de contacto, o canal, especifica cómo se inició la solicitud de servicio. Entre los canales habituales se incluyen el portal de servicios, el correo electrónico, la llamada telefónica o una alerta automatizada. Comprender el canal es importante para analizar las variaciones del proceso que pueden estar influidas por el método de envío. Por ejemplo, las solicitudes enviadas a través del portal pueden estar más estructuradas y automatizadas, lo que permite procesarlas más rápido que las enviadas por correo electrónico. Este análisis ayuda a promover canales más eficientes. Por qué es importante Ayuda a identificar cómo influyen los distintos canales de envío en la eficiencia del proceso, el nivel de automatización y los tiempos de ciclo generales, y orienta las iniciativas para optimizar las interacciones con los usuarios. Dónde obtenerlo Tablas Request [sc_request] o Interaction [interaction] de ServiceNow. El campo suele denominarse 'contact_type'. Ejemplos PortalCorreo electrónicoTeléfonoAutoservicio
	Código de resolución ResolutionCode	Código que categoriza la resolución final de la solicitud de servicio.
Descripción El código de resolución es una clasificación estructurada de la forma en que se resolvió finalmente una solicitud de servicio. Algunos ejemplos son 'Fulfilled by Automation', 'User Error' o 'No Longer Required'. Este atributo es fundamental para el Dashboard de análisis de causas raíz de los retrasos. Al correlacionar los códigos de resolución con tiempos de ciclo prolongados o tasas elevadas de retrabajo, los analistas pueden identificar problemas sistémicos. Por ejemplo, si las solicitudes con el código 'Incomplete Information' se procesan sistemáticamente con lentitud, esto apunta a un problema en la fase inicial de recopilación de datos. Por qué es importante Proporciona datos estructurados sobre los resultados de las resoluciones y permite analizar las causas raíz de los retrasos, el retrabajo y otras ineficiencias del proceso. Dónde obtenerlo Request Item [sc_req_item] de ServiceNow o una tabla de tareas relacionada; el campo suele ser 'close_code' o 'resolution_code'. Ejemplos Resuelto (de forma permanente)No resuelto (no reproducible)Solicitud atendidaCancelado por la persona usuaria
	Es retrabajo IsRework	Indicador calculado que señala si una actividad es una repetición de una actividad anterior en el mismo caso.
Descripción Este indicador booleano se calcula para identificar bucles de retrabajo en una solicitud de servicio. Se marca como 'true' si la misma actividad ya se produjo antes en el mismo caso, por ejemplo, si una solicitud se asigna dos veces al mismo equipo o si se solicita información al usuario varias veces. Este atributo es esencial para el Dashboard de transferencias entre agentes e incidentes de retrabajo y para el KPI de tasa de retrabajo de solicitudes. Permite visualizar y cuantificar directamente los bucles ineficientes del proceso, que a menudo quedan ocultos en los datos agregados. Por qué es importante Identifica y cuantifica directamente el retrabajo del proceso, lo que permite analizar las causas y el impacto de los bucles ineficientes que aumentan los costes y los tiempos de ciclo. Dónde obtenerlo Se calcula durante la transformación de datos comprobando si existen apariciones anteriores del mismo nombre de actividad dentro del mismo caso. Ejemplos falsetrue
	Está automatizado IsAutomated	Indicador que señala si una actividad fue realizada por un sistema o mediante automatización.
Descripción Este atributo booleano distingue entre las actividades realizadas manualmente por un agente y las ejecutadas por un sistema automatizado, como un Workflow o una integración. Por ejemplo, 'Approval Requested' podría estar automatizada, mientras que 'Request Assigned to Agent' podría ser manual. Analizar este atributo es clave para medir y aumentar el nivel de automatización del proceso de solicitudes de servicio. Ayuda a identificar las tareas manuales que consumen más tiempo y que podrían automatizarse en el futuro, mejorando así la eficiencia y reduciendo los costes. Por qué es importante Permite medir las tasas de automatización e identificar oportunidades para automatizar tareas manuales, lo que aumenta la eficiencia y reduce los costes operativos. Dónde obtenerlo Se obtiene comprobando si el usuario que realizó una acción, por ejemplo, 'sys_updated_by', es un usuario de sistema o de integración designado. Ejemplos truefalse
	Hora de finalización EndTime	La marca de tiempo que indica cuándo se completó una actividad o un evento.
Descripción La hora de finalización marca la conclusión de una actividad. Es la marca de tiempo de la actividad siguiente de la secuencia y cierra efectivamente la duración de la actividad actual. Este atributo es esencial para calcular cuánto tarda cada paso del proceso. Al comparar la hora de inicio y la hora de finalización de una actividad, los analistas pueden calcular los tiempos de procesamiento y de espera. Esto es fundamental para identificar cuellos de botella, medir la eficiencia de los recursos y supervisar el rendimiento frente a objetivos basados en el tiempo. Por qué es importante Este atributo es necesario para calcular la duración de cada actividad, un componente esencial del análisis de rendimiento, la identificación de cuellos de botella y los estudios de utilización de recursos. Dónde obtenerlo Es un atributo derivado que se calcula tomando el «StartTime» del evento siguiente del caso. Ejemplos 2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
	Número de reaperturas ReopenCount	Número de veces que una solicitud de servicio se ha reabierto después de resolverse.
Descripción Este atributo es un contador que registra cuántas veces una solicitud de servicio pasó de un estado resuelto o cerrado a un estado abierto o en curso. Un valor superior a cero indica que la resolución inicial no tuvo éxito. Esta métrica es un indicador directo del retrabajo y un componente clave del KPI de tasa de resolución en el primer intento. Un número elevado de reaperturas sugiere problemas en la calidad de la resolución, un cumplimiento incompleto o una interpretación incorrecta de las necesidades del usuario. Todo ello reduce la eficiencia del proceso y la satisfacción del usuario. Por qué es importante Cuantifica el retrabajo y la calidad de la resolución. Un número elevado de reaperturas apunta a ineficiencias, una baja tasa de resolución en el primer intento y una menor satisfacción del cliente. Dónde obtenerlo Tablas Request [sc_request] o Request Item [sc_req_item] de ServiceNow, campo 'reopen_count'. Ejemplos 012
	Puntuación de satisfacción SatisfactionScore	Valoración de satisfacción del cliente proporcionada por quien realizó la solicitud al cerrarse.
Descripción Este atributo registra la puntuación de satisfacción, normalmente en una escala de 1 a 5, que el usuario final envía después de resolver su solicitud de servicio. Es una medida directa de la calidad percibida del servicio. Estos datos son esenciales para el Dashboard de análisis del impacto en la satisfacción del cliente. Permiten correlacionar directamente las métricas del proceso, como el tiempo de ciclo, el retrabajo y las transferencias, con la experiencia final del cliente. Así se puede demostrar el valor de las mejoras del proceso al vincular la eficiencia operativa con los resultados para el cliente. Por qué es importante Relaciona directamente las métricas de rendimiento del proceso con los resultados para el cliente y ayuda a cuantificar el impacto de las ineficiencias del proceso en la experiencia del usuario. Dónde obtenerlo Suele encontrarse en una tabla Survey [asmt_assessment_instance] relacionada, vinculada a la solicitud original. Ejemplos 5431
	Se resuelve en el primer intento IsFirstPassResolution	Indicador que señala si la solicitud se resolvió en el primer intento sin ninguna reapertura.
Descripción Este atributo calculado es un indicador booleano que solo es 'true' si la solicitud de servicio se resolvió y cerró sin volver a abrirse. Es un indicador clave de la calidad y eficacia de la resolución proporcionada por la mesa de servicio. Esta métrica respalda directamente el KPI de tasa de resolución en el primer intento. Una tasa elevada es deseable, ya que indica eficiencia y un servicio de alta calidad, lo que se traduce en una mayor satisfacción del cliente. Analizar los atributos de los casos que no se resuelven en el primer intento puede revelar causas raíz como una formación insuficiente, documentación deficiente o un diagnóstico inicial incorrecto. Por qué es importante Mide la calidad y la eficiencia del proceso de resolución. Una tasa baja de resolución en el primer intento indica problemas subyacentes que provocan retrabajo y frustración del cliente. Dónde obtenerlo Se calcula a nivel de caso. Un caso se considera resuelto en el primer intento si su 'ReopenCount' es cero. Ejemplos truefalse
	Tiempo de ciclo del caso CaseCycleTime	Tiempo total transcurrido desde la creación hasta el cierre definitivo de una solicitud de servicio.
Descripción El tiempo de ciclo del caso es una métrica calculada que mide la duración total de una solicitud de servicio, desde la marca de tiempo del primer evento hasta la marca de tiempo del último. Representa el tiempo completo de procesamiento de extremo a extremo desde el punto de vista del cliente. Es un indicador clave de rendimiento (KPI) principal de la eficiencia general del proceso. Se utiliza en Dashboards de alto nivel para supervisar el rendimiento frente a los objetivos y analizar las tendencias a lo largo del tiempo. Puede segmentarse por dimensiones como categoría o prioridad para identificar qué tipos de solicitudes tardan más. Por qué es importante Este KPI crítico mide el rendimiento del proceso de extremo a extremo. Es esencial para la supervisión de alto nivel, la comparación con referencias y la identificación de áreas de mejora. Dónde obtenerlo Se calcula restando el 'StartTime' mínimo al 'EndTime' máximo para cada 'ServiceRequestID' único. Ejemplos 2 10:30:000 04:15:2210 00:05:00

Obligatorio Recomendado Opcional

Actividades de la gestión de solicitudes de servicio

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir el proceso con precisión e identificar cuellos de botella.

6 Recomendado 8 Opcional

	Actividad	Descripción
	Información solicitada al usuario	Ocurre cuando la persona agente responsable de la ejecución necesita más información de quien realizó la solicitud para continuar. Normalmente se infiere cuando el estado de la solicitud cambia a un valor como «Awaiting User Info».
Por qué es importante Esta actividad es fundamental para el Dashboard «Requestor Information Delay Analysis», ya que ayuda a cuantificar el tiempo perdido mientras se espera información externa del usuario. Dónde obtenerlo Se infiere a partir del cambio del campo de estado de sc_req_item a un estado designado de «awaiting information». El cambio se registra en la tabla sys_audit. Recopilar Identifique la marca de tiempo en la que sc_req_item.state cambia a «Awaiting User Info». Tipo de evento inferred
	Solicitud aprobada	Esta actividad indica que la solicitud se ha aprobado oficialmente y puede pasar a la etapa de ejecución. Se captura cuando una persona aprobadora marca el registro de aprobación asociado como «approved».
Por qué es importante Este hito clave marca la transición de la fase de aprobación a la fase de ejecución. Analizar el tiempo necesario para llegar a este paso es fundamental para comprender los retrasos previos a la ejecución. Dónde obtenerlo Se infiere a partir del cambio del campo de estado del registro sysapproval_approver relacionado a «approved», lo que posteriormente activa un cambio de estado en sc_req_item. Recopilar Identifique la marca de tiempo en la que sysapproval_approver.state pasa a ser «approved». Tipo de evento inferred
	Solicitud asignada a un agente	Esta actividad ocurre cuando se asigna a una persona agente concreta el trabajo sobre la solicitud de servicio. Se captura mediante el seguimiento de los cambios en el campo «Assigned to» de la solicitud o de sus tareas de ejecución.
Por qué es importante Es fundamental para medir las transferencias, calcular la carga de trabajo específica de cada agente y analizar los tiempos de espera en cola antes de que una persona empiece a trabajar en una solicitud. Dónde obtenerlo Se infiere a partir de un cambio en el campo assigned_to de las tablas sc_req_item o sc_task. El historial de cambios se registra en la tabla sys_audit. Recopilar Realice el seguimiento de los cambios en el campo assigned_to en sys_audit. Tipo de evento inferred
	Solicitud de servicio cerrada	Marca el final definitivo del ciclo de vida de la solicitud de servicio. Normalmente ocurre de forma automática después de que la solicitud permanezca un periodo determinado en el estado «Resolved», durante el cual el usuario puede reabrirla.
Por qué es importante Es el evento de finalización satisfactoria principal del proceso. También puede analizarse el tiempo entre «Resolved» y «Closed» para comprender las políticas de cierre automático. Dónde obtenerlo Se infiere a partir de la actualización del campo de estado de sc_req_item a un estado final cerrado, como «Closed Complete». Se registra en la tabla sys_audit. Recopilar Identifique la marca de tiempo en la que sc_req_item.state cambia a «Closed Complete». Tipo de evento inferred
	Solicitud de servicio creada	Esta actividad marca el inicio del ciclo de vida de la solicitud de servicio y se registra cuando un usuario envía una solicitud a través del catálogo de servicios. El sistema la captura como el evento de creación de un nuevo registro en la tabla sc_req_item (Requested Item).
Por qué es importante Este es el evento de inicio principal del proceso. Es esencial para calcular el tiempo total del ciclo y analizar el volumen y los patrones de envío de solicitudes. Dónde obtenerlo Este es un evento explícito capturado a partir de la marca de tiempo de creación (campo sys_created_on) del registro en la tabla sc_req_item. Recopilar Utilice la marca de tiempo sys_created_on del registro sc_req_item. Tipo de evento explicit
	Solicitud de servicio resuelta	Esta actividad indica que la persona agente responsable de la ejecución ha completado el trabajo y ha proporcionado una solución. Se captura cuando el estado de la solicitud se actualiza a «Resolved» o a un estado similar.
Por qué es importante Es un hito fundamental que normalmente detiene el contador del SLA. Marca el final del trabajo activo de ejecución y es un componente clave del cálculo del tiempo total de resolución. Dónde obtenerlo Se infiere a partir de la actualización del campo de estado de sc_req_item a «Resolved» o a un estado terminal similar antes del cierre definitivo. El cambio se registra en la tabla sys_audit. Recopilar Identifique la marca de tiempo en la que sc_req_item.state cambia a «Resolved». Tipo de evento inferred
	Aprobación solicitada	Representa el momento en que una solicitud de servicio se envía para que la apruebe un gerente u otra persona autorizada. Normalmente se infiere cuando el estado de la solicitud cambia a «Pending Approval» o a un estado similar.
Por qué es importante El seguimiento de las aprobaciones ayuda a identificar cuellos de botella en el proceso de aprobación y a medir cuánto tiempo esperan las solicitudes la autorización antes de que pueda comenzar su ejecución. Dónde obtenerlo Se infiere a partir del cambio del campo de estado de sc_req_item a un valor de aprobación pendiente o de la creación de un registro correspondiente en la tabla sysapproval_approver. Los cambios se registran en la tabla sys_audit. Recopilar Identifique la marca de tiempo en la que sc_req_item.state cambia a «Pending Approval». Tipo de evento inferred
	Información proporcionada por el usuario	Esta actividad marca el momento en que quien realizó la solicitud proporciona la información necesaria. Se infiere cuando la solicitud sale del estado «Awaiting User Info» y vuelve a un estado activo, como «Work in Progress».
Por qué es importante Junto con «Information Requested from User», esta actividad permite medir con precisión los retrasos provocados por el usuario y evaluar la eficiencia del proceso de comunicación. Dónde obtenerlo Se infiere a partir del cambio del campo de estado de sc_req_item desde un estado de «awaiting information» a un estado activo. A menudo se activa cuando el usuario añade un comentario o responde a un correo electrónico. Recopilar Identifique la marca de tiempo en la que el estado cambia de «Awaiting User Info» a «Work in Progress». Tipo de evento inferred
	Proveedor externo involucrado	Representa la transferencia de una solicitud de servicio o de una de sus tareas a un proveedor externo para su ejecución. Puede inferirse a partir de la asignación a un grupo específico del proveedor o de una marca en la solicitud.
Por qué es importante Esta actividad permite analizar el rendimiento del proveedor y su impacto en el ciclo de vida completo de la solicitud, algo fundamental para el Dashboard «External Vendor Engagement Cycle». Dónde obtenerlo Normalmente se infiere. Puede basarse en que assignment_group se establezca en el grupo de un proveedor o en que se active un campo de marca específico en el registro sc_req_item o sc_task. Recopilar Identifique el cambio de assignment_group a un grupo de proveedor conocido. Tipo de evento inferred
	Solicitud asignada a un grupo	Indica que la solicitud de servicio se ha asignado a un equipo o grupo específico de ejecución. Este evento se infiere al detectar un cambio en el campo de grupo de asignación del elemento de solicitud o de sus tareas asociadas.
Por qué es importante El seguimiento de las asignaciones a grupos ayuda a analizar la distribución de la carga de trabajo entre los equipos e identificar retrasos antes de que la solicitud se dirija a las personas responsables adecuadas. Dónde obtenerlo Se infiere a partir de un cambio en el campo assignment_group de las tablas sc_req_item o sc_task. El historial de cambios se registra en la tabla sys_audit. Recopilar Realice el seguimiento de los cambios en el campo assignment_group en sys_audit. Tipo de evento inferred
	Solicitud cancelada	Esta actividad representa un estado terminal para las solicitudes canceladas antes de completarse, ya sea por el usuario o por un agente. Se captura cuando el estado de la solicitud se establece en «Cancelled» o «Closed Cancelled».
Por qué es importante Es un evento de finalización no satisfactoria clave. Analizar por qué se cancelan las solicitudes puede aportar información sobre las necesidades de los usuarios, las ineficiencias del proceso o los cambios en las prioridades empresariales. Dónde obtenerlo Se infiere a partir de la actualización del campo de estado de sc_req_item a un estado final cancelado, como «Closed Cancelled». El cambio se registra en la tabla sys_audit. Recopilar Identifique la marca de tiempo en la que sc_req_item.state cambia a «Cancelled». Tipo de evento inferred
	Solicitud reabierta	Esta actividad captura los casos en los que una solicitud marcada previamente como resuelta vuelve a un estado abierto. Se infiere a partir de un cambio de estado de «Resolved» a «Work in Progress» o a un estado similar.
Por qué es importante Es una medida directa del retrabajo y resulta fundamental para calcular el KPI «First-Pass Resolution Rate». Un número elevado indica una calidad deficiente de la solución o una resolución incompleta. Dónde obtenerlo Se infiere a partir de un cambio en el campo de estado de sc_req_item, que pasa de un estado resuelto o cerrado a un estado abierto o en curso. Este cambio se registra en sys_audit. Recopilar Detecte en sys_audit el cambio de estado de «Resolved» a «Work in Progress». Tipo de evento inferred
	Solicitud rechazada	Esta actividad representa el resultado en el que una solicitud se rechaza formalmente durante la fase de aprobación. Es una ruta alternativa hacia el cierre y se captura cuando una persona aprobadora marca la solicitud como «rejected».
Por qué es importante El seguimiento de los rechazos ayuda a identificar solicitudes no válidas o mal dirigidas, problemas en el proceso de envío y una ruta de excepción importante para el análisis. Dónde obtenerlo Se infiere a partir del cambio del campo de estado del registro sysapproval_approver relacionado a «rejected». Normalmente, esto establece el sc_req_item principal en un estado cerrado e incompleto. Recopilar Identifique la marca de tiempo en la que sysapproval_approver.state pasa a ser «rejected». Tipo de evento inferred
	Tarea de ejecución creada	Representa la creación de un elemento de trabajo o tarea específica necesaria para ejecutar la solicitud de servicio. Es un evento explícito que se registra cuando se crea un nuevo registro en la tabla Catalog Task.
Por qué es importante En las solicitudes complejas, analizar la creación y finalización de cada tarea ofrece una visión más detallada del proceso de ejecución y de los puntos en los que se producen retrasos. Dónde obtenerlo Es un evento explícito capturado a partir de la marca de tiempo de creación (campo sys_created_on) de un registro de la tabla sc_task vinculado a sc_req_item. Recopilar Utilice la marca de tiempo sys_created_on de los registros sc_task. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de ServiceNow

Pasos

Comprenda el enfoque de exportación múltiple: Debido a la naturaleza del modelo de datos de ServiceNow, una sola exportación no puede capturar todos los eventos necesarios. Debe realizar varias exportaciones desde distintas tablas y combinar los datos externamente. Las tablas principales son Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task) y Audit (sys_audit).
Exportación 1: datos principales de la solicitud de servicio: Acceda a la tabla Requested Item escribiendo sc_req_item.list en el navegador de filtros. Aplique un filtro para el intervalo de fechas deseado, por ejemplo, [Created] [on] [Last 6 months]. Añada columnas como Number, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to, Priority y Made SLA. Haga clic con el botón derecho en cualquier encabezado de columna, seleccione Export y elija CSV o XLSX.
Exportación 2: decisiones de aprobación: Acceda a la tabla Approval escribiendo sysapproval_approver.list. Filtre la lista para mostrar solo los registros relacionados con solicitudes de servicio: [Source table] [is] [sc_req_item] Y [Created] [on] [Last 6 months]. Añada columnas como Approving.Number, State, Sys Created On y Sys Updated On. Exporte la lista filtrada.
Exportación 3: creación de tareas de cumplimiento: Acceda a la tabla Catalog Task escribiendo sc_task.list. Filtre la lista para vincularla con las solicitudes del periodo elegido, por ejemplo, [Request Item.Created] [on] [Last 6 months]. Añada las columnas Request Item.Number, Sys Created On, State, Assignment group y Assigned to. Exporte los datos.
Exportación 4: historial detallado de actividades: Acceda a la tabla Audit mediante sys_audit.list. Esta tabla contiene cambios históricos de campos. Cree un filtro para [Table name] [is] [sc_req_item] Y [Created] [on] [Last 6 months] Y [Field name] [is one of] [state, assignment_group, assigned_to]. Añada las columnas Document key, Field name, Old value, New value y Sys Created On. Exporte estos datos. Tenga en cuenta que el acceso a esta tabla puede requerir permisos elevados.
Combine y transforme los datos: Utilice una herramienta como Microsoft Excel, Python con pandas o una herramienta específica de preparación de datos para combinar los cuatro archivos exportados. Use el número de solicitud de servicio o el Sys ID como clave común para unir los datos.
Cree la estructura del Registro de eventos: En el archivo combinado, cree las columnas obligatorias: ServiceRequestID, ActivityName y EventTime.
Asigne los datos sin procesar a las actividades: Cree una fila nueva para cada actividad distinta. Por ejemplo:
- Para Service Request Created, use Sys Created On de la exportación de sc_req_item.
- Para Request Approved, use Sys Updated On de la exportación de sysapproval_approver cuando State cambie a 'approved'.
- Para Request Assigned to Group, busque en la exportación de sys_audit la fila cuyo Field name sea assignment_group y use Sys Created On de ese registro de auditoría como EventTime.
Complete las columnas de atributos: Rellene los atributos AssignedTo, AssignmentGroup, Priority, State, Category y MadeSLA para cada fila de actividad. Los valores deben reflejar el estado de la solicitud en el momento del evento.
Añada las columnas de metadatos: Añada SourceSystem con un valor estático como 'ServiceNow' y LastDataUpdate con la marca de tiempo de la extracción.
Finalice y exporte: Guarde los datos finales transformados y combinados como un único archivo CSV y asegúrese de que los encabezados de columna coincidan con los requisitos de importación.

Configuración

Tablas de destino: La extracción requiere datos de varias tablas:
- sc_req_item: Contiene los registros principales de solicitudes de servicio (Requested Item).
- sysapproval_approver: Almacena los registros de aprobación relacionados con las solicitudes.
- sc_task: Contiene las tareas individuales de resolución generadas para una solicitud.
- sys_audit: Proporciona un historial detallado de los cambios de campos, esencial para realizar el seguimiento de las asignaciones y las transiciones de estado.
Filtrado por intervalo de fechas: Es fundamental aplicar un filtro de intervalo de fechas coherente, como Created on Last 6 months, a todas las exportaciones para garantizar la integridad de los datos. Se recomienda un periodo de 3 a 6 meses para equilibrar el volumen y la información obtenida.
Filtros clave: Además del intervalo de fechas, use filtros como Source table is sc_req_item en la tabla de aprobaciones y Table name is sc_req_item en la tabla de auditoría para aislar los registros relevantes.
Columnas esenciales: Asegúrese de exportar identificadores clave como Número y Sys ID (document key en la auditoría) para unir los conjuntos de datos. Las marcas de tiempo como Sys Created On, Sys Updated On, Resuelto y Cerrado son fundamentales para crear el registro de eventos.
Requisitos previos: Se necesita una cuenta de usuario de ServiceNow con, como mínimo, el rol itil para acceder a la mayoría de las tablas necesarias. La exportación de la tabla sys_audit puede requerir el rol admin u otro rol especializado debido a su tamaño y sensibilidad.

a Consulta de ejemplo config

This method uses the ServiceNow user interface for filtering and exporting, so there is no single script. The configuration consists of setting filters and choosing columns for multiple list views.

**Configuration for Export 1: Requested Items**
*   **Table**: `sc_req_item`
*   **Filter Conditions**:
    1. `[Created] [on] [Last 6 months]`
    2. `[Active] [is one of] [true, false]` (Or adjust based on process scope)
*   **Columns to Add**: `Number`, `Sys ID`, `Sys Created On`, `Resolved`, `Closed`, `State`, `Stage`, `Assignment group`, `Assigned to`, `Priority`, `Category`, `Made SLA`

**Configuration for Export 2: Approvals**
*   **Table**: `sysapproval_approver`
*   **Filter Conditions**:
    1. `[Source table] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
*   **Columns to Add**: `Approving`, `Approving.Number`, `State`, `Sys Created On`, `Sys Updated On`

**Configuration for Export 3: Catalog Tasks**
*   **Table**: `sc_task`
*   **Filter Conditions**:
    1. `[Request Item.Created] [on] [Last 6 months]`
*   **Columns to Add**: `Request Item`, `Request Item.Number`, `Sys Created On`, `Sys Updated On`, `State`, `Assignment group`, `Assigned to`

**Configuration for Export 4: Audit History**
*   **Table**: `sys_audit`
*   **Filter Conditions**:
    1. `[Table name] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
    3. `[Field name] [is one of] [state, assignment_group, assigned_to]`
*   **Columns to Add**: `Document key`, `Table name`, `Field name`, `Old value`, `New value`, `Sys Created On`

Pasos

Prepare el entorno de Python: Asegúrese de tener instalada la versión 3.6 o posterior de Python. Instale las bibliotecas necesarias con pip: pip install requests pandas.
Configure los parámetros del script: Abra el script de Python en un editor. Busque la sección de configuración al principio del script. Introduzca la URL de su instancia de ServiceNow, por ejemplo, https://your-instance.service-now.com, un nombre de usuario y una contraseña para una cuenta de servicio con los permisos de lectura adecuados en las tablas necesarias.
Defina el intervalo de fechas de extracción: Defina las fechas de inicio y fin de la extracción modificando las variables start_date y end_date. Se recomienda comenzar con un intervalo más corto, por ejemplo, 3 meses, para probar el script y comprobar el rendimiento.
Revise los nombres de tablas y campos: El script utiliza nombres de tablas estándar de ServiceNow, como sc_req_item, sys_audit y sc_task. Compruebe que estos nombres de tablas y campos coincidan con su configuración de ServiceNow. Ajústelos en el script si su instancia utiliza tablas o campos personalizados.
Ejecute el script de Python: Ejecute el script desde la línea de comandos o el terminal mediante el comando: python your_script_name.py. El script se conectará a la API de ServiceNow, recuperará los datos de cada actividad especificada y mostrará mensajes de progreso en la consola.
Gestione la paginación de la API: El script incluye una función para gestionar automáticamente la paginación. Realizará varias llamadas a la API si el número de registros supera el límite de página (sysparm_limit), hasta recuperar todos los datos del intervalo de fechas especificado.
Transforme y combine los datos: El script procesa la respuesta JSON sin procesar de la API para cada tipo de actividad. Extrae los campos necesarios, los asigna al esquema del Registro de eventos (ServiceRequestID, ActivityName, EventTime, etc.) y los combina en un conjunto de datos unificado.
Genere el archivo del Registro de eventos: Cuando finalice, el script guardará el Registro de eventos final como un archivo CSV denominado servicenow_servicerequest_eventlog.csv en el mismo directorio desde el que se ejecutó el script.
Prepárese para la carga: Abra el archivo CSV generado en un programa de hojas de cálculo para revisar que los datos estén completos y sean correctos. Asegúrese de que los encabezados de columna coincidan con el esquema de ProcessMind antes de cargarlo.

Configuración

URL de la instancia de ServiceNow: URL base de su instancia de ServiceNow, por ejemplo, https://your-instance.service-now.com.
Autenticación: Se requiere un nombre de usuario y una contraseña de una cuenta de servicio con acceso de lectura a las tablas sc_req_item, sys_audit, sysapproval_approver y sc_task.
Intervalo de fechas: Establezca las variables start_date y end_date del script para definir el periodo de extracción. Para el análisis inicial, se recomienda un periodo de 3 a 6 meses.
Límite de página (sysparm_limit): El script establece un límite para el número de registros devueltos por llamada a la API. El valor predeterminado es 1000, una cifra segura para la mayoría de las instancias. Puede ajustarlo según el rendimiento del sistema y los límites de frecuencia de la API.
Filtros de consulta (sysparm_query): El script utiliza filtros de fecha (sys_created_on>=...) para limitar la extracción de datos. Puede añadir más filtros a la cadena de consulta, como un filtro por elemento de catálogo o grupo de asignación específico, para reducir el volumen de datos, por ejemplo, active=true^category=hardware.
Valores mostrados: El parámetro sysparm_display_value=true se utiliza para recuperar nombres legibles en los campos de referencia en lugar de valores internos sys_id. Esto es fundamental para atributos como AssignmentGroup y AssignedTo.

a Consulta de ejemplo python

import requests
import pandas as pd
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
SN_INSTANCE = class="hl-string">'https://[your-instance].service-now.com'
SN_USER = class="hl-string">'[your-username]'
SN_PASSWORD = class="hl-string">'[your-password]'

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD)
start_date = class="hl-string">'[YYYY-MM-DD]'
end_date = class="hl-string">'[YYYY-MM-DD]'

class=class="hl-string">"hl-comment"># --- End Configuration ---

def query_servicenow_table(table, query, fields):
    class="hl-string">"""Queries a ServiceNow table with pagination."""
    all_records = []
    offset = 0
    limit = 1000
    
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    url = fclass="hl-string">"{SN_INSTANCE}/api/now/table/{table}"
    
    while True:
        params = {
            class="hl-string">'sysparm_query': query,
            class="hl-string">'sysparm_fields': class="hl-string">','.join(fields),
            class="hl-string">'sysparm_limit': limit,
            class="hl-string">'sysparm_offset': offset,
            class="hl-string">'sysparm_display_value': class="hl-string">'true',
            class="hl-string">'sysparm_exclude_reference_link': class="hl-string">'true'
        }
        
        print(fclass="hl-string">"Querying {table} with offset {offset}...")
        response = requests.get(url, auth=(SN_USER, SN_PASSWORD), headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
        
        records = response.json().get(class="hl-string">'result', [])
        if not records:
            break
        all_records.extend(records)
        offset += limit
        
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    all_events = []
    source_system = class="hl-string">'ServiceNow'
    last_data_update = datetime.datetime.now().isoformat()

    class=class="hl-string">"hl-comment"># Define common attributes to fetch for context
    context_fields = [class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state', class="hl-string">'cat_item.category', class="hl-string">'made_sla']

    class=class="hl-string">"hl-comment"># 1. Service Request Created
    query = fclass="hl-string">'sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    fields = [class="hl-string">'sys_created_on'] + context_fields
    req_items = query_servicenow_table(class="hl-string">'sc_req_item', query, fields)
    for item in req_items:
        all_events.append({
            class="hl-string">'ServiceRequestID': item[class="hl-string">'number'],
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': item[class="hl-string">'sys_created_on'],
            class="hl-string">'AssignedTo': item.get(class="hl-string">'assigned_to'),
            class="hl-string">'AssignmentGroup': item.get(class="hl-string">'assignment_group'),
            class="hl-string">'Priority': item.get(class="hl-string">'priority'),
            class="hl-string">'State': item.get(class="hl-string">'state'),
            class="hl-string">'Category': item.get(class="hl-string">'cat_item.category'),
            class="hl-string">'MadeSLA': item.get(class="hl-string">'made_sla')
        })

    class=class="hl-string">"hl-comment"># Get a list of relevant document keys (sys_id of sc_req_item)
    doc_keys_query = fclass="hl-string">'tablename=sc_req_item^sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    audit_records = query_servicenow_table(class="hl-string">'sys_audit', doc_keys_query, [class="hl-string">'documentkey'])
    relevant_doc_keys = list(set([rec[class="hl-string">'documentkey'] for rec in audit_records]))
    
    class=class="hl-string">"hl-comment"># Query audit and other tables in batches to avoid long URLs
    batch_size = 50
    for i in range(0, len(relevant_doc_keys), batch_size):
        key_batch = relevant_doc_keys[i:i+batch_size]
        key_batch_str = class="hl-string">','.join(key_batch)

        class=class="hl-string">"hl-comment"># 2-14. Activities from sys_audit, sysapproval_approver, sc_task
        class=class="hl-string">"hl-comment"># Fetch sc_req_item details for context
        ritm_context = {ritm[class="hl-string">'sys_id']: ritm for ritm in query_servicenow_table(class="hl-string">'sc_req_item', fclass="hl-string">'sys_idIN{key_batch_str}', [class="hl-string">'sys_id'] + context_fields)}

        class=class="hl-string">"hl-comment"># Activities based on state changes and field updates from sys_audit
        audit_query = fclass="hl-string">'documentkeyIN{key_batch_str}^fieldnameINassignment_group,assigned_to,state'
        audit_log = query_servicenow_table(class="hl-string">'sys_audit', audit_query, [class="hl-string">'documentkey', class="hl-string">'sys_created_on', class="hl-string">'fieldname', class="hl-string">'newvalue', class="hl-string">'oldvalue'])
        for log in audit_log:
            context = ritm_context.get(log[class="hl-string">'documentkey'], {})
            if not context:
                continue

            event = {
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'EventTime': log[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'),
                class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'),
                class="hl-string">'Priority': context.get(class="hl-string">'priority'),
                class="hl-string">'State': context.get(class="hl-string">'state'),
                class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'),
                class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla'),
            }
            activity = None
            class=class="hl-string">"hl-comment"># Map audit entries to activities
            if log[class="hl-string">'fieldname'] == class="hl-string">'assignment_group' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Group'
                event[class="hl-string">'AssignmentGroup'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'assigned_to' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Agent'
                event[class="hl-string">'AssignedTo'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'state':
                class=class="hl-string">"hl-comment"># Define state mappings, may need customization
                state_map = {
                    class="hl-string">'Awaiting User Info': class="hl-string">'Information Requested from User',
                    class="hl-string">'Resolved': class="hl-string">'Service Request Resolved',
                    class="hl-string">'Closed Complete': class="hl-string">'Service Request Closed',
                    class="hl-string">'Closed Cancelled': class="hl-string">'Request Cancelled'
                }
                if log[class="hl-string">'newvalue'] in state_map:
                    activity = state_map[log[class="hl-string">'newvalue']]
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Awaiting User Info':
                    activity = class="hl-string">'Information Provided by User'
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Resolved':
                    activity = class="hl-string">'Request Reopened'
                class=class="hl-string">"hl-comment"># For class="hl-string">'Approval Requested', class="hl-string">'External Vendor Engaged' - more complex logic might be needed
                class=class="hl-string">"hl-comment"># This is a common inference. Adjust if you have a specific state.
                if log[class="hl-string">'newvalue'] == class="hl-string">'Pending Approval':
                     activity = class="hl-string">'Approval Requested'

            if activity:
                event[class="hl-string">'ActivityName'] = activity
                all_events.append(event)

        class=class="hl-string">"hl-comment"># Approval Activities
        approval_query = fclass="hl-string">'sysapprovalIN{key_batch_str}'
        approvals = query_servicenow_table(class="hl-string">'sysapproval_approver', approval_query, [class="hl-string">'sysapproval', class="hl-string">'sys_updated_on', class="hl-string">'state'])
        for appr in approvals:
            context = ritm_context.get(appr[class="hl-string">'sysapproval'], {})
            if not context: continue
            activity = None
            if appr[class="hl-string">'state'] == class="hl-string">'approved':
                activity = class="hl-string">'Request Approved'
            elif appr[class="hl-string">'state'] == class="hl-string">'rejected':
                activity = class="hl-string">'Request Rejected'
            if activity:
                all_events.append({
                    class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': appr[class="hl-string">'sys_updated_on'],
                    class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
                })

        class=class="hl-string">"hl-comment"># Fulfillment Task Creation
        task_query = fclass="hl-string">'request_itemIN{key_batch_str}'
        tasks = query_servicenow_table(class="hl-string">'sc_task', task_query, [class="hl-string">'request_item', class="hl-string">'sys_created_on', class="hl-string">'number'])
        for task in tasks:
            context = ritm_context.get(task[class="hl-string">'request_item'], {})
            if not context: continue
            all_events.append({
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'ActivityName': fclass="hl-string">'Fulfillment Task Created - {task["number"]}',
                class="hl-string">'EventTime': task[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
            })

    class=class="hl-string">"hl-comment"># Post-processing and saving
    if not all_events:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = source_system
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to match schema
    final_cols = [class="hl-string">'ServiceRequestID', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'State', class="hl-string">'Category', class="hl-string">'MadeSLA']
    df = df[final_cols]
    
    df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], inplace=True)
    df.to_csv(class="hl-string">'servicenow_servicerequest_eventlog.csv', index=False)
    print(class="hl-string">"Extraction complete. File saved to servicenow_servicerequest_eventlog.csv")

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

Pasos

Configurar el usuario de API de ServiceNow: Cree un usuario específico en su instancia de ServiceNow para esta integración. Asígnele los roles rest_service e itil. Asegúrese de que el usuario tenga permisos de lectura (ACL) en las siguientes tablas: Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver) y Audit (sys_audit).
Preparar el entorno de desarrollo: Instale Node.js en el equipo que utilizará para la extracción. Después, inicialice un proyecto nuevo de Node.js e instale la biblioteca axios para realizar solicitudes HTTP y fast-csv para escribir el archivo de salida. Para ello, ejecute npm install axios fast-csv en la terminal.
Configurar el script de extracción: Copie el código JavaScript proporcionado en un archivo, por ejemplo, extract.js. Complete los valores de marcador de posición al principio del script con la URL de su instancia de ServiceNow, el nombre de usuario de la API y la contraseña.
Definir el intervalo de fechas y los filtros: Modifique las variables startDate y endDate del script para definir el periodo de extracción. También puede añadir más filtros a las cadenas sysparm_query de cada actividad para delimitar el alcance, por ejemplo, filtrando por un elemento de catálogo o un grupo de asignación específicos.
Comprender las llamadas a la API: El script realiza llamadas a la API independientes para cada una de las 14 actividades requeridas. Los eventos como la creación se consultan directamente en sus tablas de origen (sc_req_item, sc_task), mientras que los cambios de estado y las asignaciones se obtienen consultando la tabla sys_audit para detectar actualizaciones de campos específicos.
Ejecutar el script: Ejecute el script desde la terminal con el comando node extract.js. El script se conectará a la Table API de ServiceNow, recuperará los datos de cada actividad y gestionará automáticamente la paginación.
Procesar los datos: A medida que se recuperan los datos, el script transforma la respuesta JSON de ServiceNow en un formato estandarizado de Registro de eventos y asigna los campos a columnas como ServiceRequestID, ActivityName y EventTime.
Combinar y consolidar los resultados: El script reúne los resultados de todas las llamadas a la API en una única matriz unificada que representa el Registro de eventos completo.
Generar el archivo de salida: Una vez recuperados y procesados todos los datos, el script utiliza la biblioteca fast-csv para escribir el Registro de eventos consolidado en un archivo llamado servicenow_event_log.csv, ubicado en el mismo directorio.
Preparar la carga: El archivo CSV generado incluye las columnas necesarias para Process Mining. No es necesario aplicar ningún formato adicional antes de cargarlo en la plataforma ProcessMind.

Configuración

URL de la instancia de ServiceNow: La URL base de su entorno de ServiceNow, por ejemplo, https://your-instance.service-now.com.
Credenciales de la API: Un nombre de usuario y una contraseña válidos de un usuario de ServiceNow con los permisos de lectura y los roles necesarios (rest_service, itil).
Intervalo de fechas: Recomendamos extraer datos de un periodo de 3 a 6 meses para obtener un conjunto de datos representativo. Este periodo se configura en el script mediante las variables startDate y endDate, que se aplican a los campos de fecha y hora correspondientes en las consultas a la API.
sysparm_query: Es el parámetro de URL principal para filtrar registros. El script lo utiliza ampliamente para aislar eventos específicos, como registros creados dentro de un intervalo de fechas o registros de auditoría que muestran un cambio de estado de 'Resolved' a 'Work in Progress'.
sysparm_fields: Este parámetro especifica qué columnas debe devolver la llamada a la API. Su uso mejora considerablemente el rendimiento al reducir la cantidad de datos transferidos. El script preconfigura los campos necesarios para cada consulta.
Límite de paginación (sysparm_limit): El script está configurado para recuperar registros en lotes de 1.000. Puede ajustar este valor, pero recomendamos mantenerlo por debajo del máximo de ServiceNow, que suele ser de 10.000, para garantizar la estabilidad.

a Consulta de ejemplo javascript

const axios = require('axios');
const fs = require('fs');
const { format, writeToStream } = require('@fast-csv/format');

// --- Configuration ---
const SN_INSTANCE = 'https://YOUR_INSTANCE.service-now.com';
const SN_USER = 'YOUR_API_USER';
const SN_PASSWORD = 'YOUR_API_PASSWORD';
const BATCH_SIZE = 1000;

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-12-31 23:59:59';

const auth = { username: SN_USER, password: SN_PASSWORD };

// --- Helper Function for Paginated API Calls ---
async function fetchAllRecords(table, query, fields, processFunction) {
    let offset = 0;
    let hasMore = true;
    let allEvents = [];

    console.log(`Starting fetch for table: ${table}`);

    while (hasMore) {
        try {
            const response = await axios.get(`${SN_INSTANCE}/api/now/table/${table}`, {
                auth,
                params: {
                    sysparm_query: query,
                    sysparm_fields: fields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset,
                    sysparm_display_value: 'true', // Get display values for reference fields
                    sysparm_exclude_reference_link: true
                }
            });

            const records = response.data.result;
            if (records.length > 0) {
                console.log(`Fetched ${records.length} records from ${table} with offset ${offset}`);
                const processedEvents = records.map(processFunction);
                allEvents.push(...processedEvents);
                offset += BATCH_SIZE;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching data from ${table}:`, error.response ? error.response.statusText : error.message);
            hasMore = false; // Stop on error
        }
    }
    return allEvents;
}

// --- Main Extraction Logic ---
async function extractServiceRequestData() {
    let finalEventLog = [];
    const now = new Date().toISOString();

    // 1. Service Request Created
    const createdEvents = await fetchAllRecords(
        'sc_req_item',
        `sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'number,sys_created_on,assigned_to,assignment_group,priority,state,cat_item.category,made_sla',
        (r) => ({
            ServiceRequestID: r.number,
            ActivityName: 'Service Request Created',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: r.assigned_to,
            AssignmentGroup: r.assignment_group,
            Priority: r.priority,
            State: r.state,
            Category: r['cat_item.category'],
            MadeSLA: r.made_sla
        })
    );
    finalEventLog.push(...createdEvents);

    // 2. Approval Requested
    const approvalRequestedEvents = await fetchAllRecords(
        'sysapproval_approver',
        `sysapproval.sys_class_name=sc_req_item^state=requested^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'sysapproval,sys_created_on',
        (r) => ({
            ServiceRequestID: r.sysapproval,
            ActivityName: 'Approval Requested',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Pending Approval', Category: null, MadeSLA: null
        })
    );
    finalEventLog.push(...approvalRequestedEvents);

    // Function to process audit records
    const processAuditRecord = (activityName) => (r) => ({
        ServiceRequestID: r['documentkey.number'],
        ActivityName: activityName,
        EventTime: r.sys_created_on,
        SourceSystem: 'ServiceNow',
        LastDataUpdate: now,
        AssignedTo: activityName === 'Request Assigned to Agent' ? r.newvalue : null,
        AssignmentGroup: activityName === 'Request Assigned to Group' ? r.newvalue : null,
        Priority: null, 
        State: ['Service Request Resolved', 'Service Request Closed', 'Request Cancelled', 'Request Reopened', 'Information Requested from User', 'Information Provided by User'].includes(activityName) ? r.newvalue : null,
        Category: null, 
        MadeSLA: null
    });
    
    // 3. Request Approved
    const approvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=approved^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Approved', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Approved', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...approvedEvents);

    // 4. Request Assigned to Group
    const assignedGroupEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Group')
    );
    finalEventLog.push(...assignedGroupEvents);

    // 5. Request Assigned to Agent
    const assignedAgentEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assigned_to^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Agent')
    );
    finalEventLog.push(...assignedAgentEvents);

    // 6. Fulfillment Task Created
    const taskCreatedEvents = await fetchAllRecords(
        'sc_task',
        `request_item.sys_class_name=sc_req_item^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'request_item.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['request_item.number'], ActivityName: 'Fulfillment Task Created', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: null, Category: null, MadeSLA: null })
    );
    finalEventLog.push(...taskCreatedEvents);

    // 7. Information Requested from User
    const infoRequestedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Requested from User')
    );
    finalEventLog.push(...infoRequestedEvents);

    // 8. Information Provided by User
    const infoProvidedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Provided by User')
    );
    finalEventLog.push(...infoProvidedEvents);

    // 9. External Vendor Engaged (Note: requires a specific vendor group name)
    const vendorEngagedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^newvalue=[Your Vendor Assignment Group Name]^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('External Vendor Engaged')
    );
    finalEventLog.push(...vendorEngagedEvents);

    // 10. Request Reopened
    const reopenedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Resolved^newvalue=Work in Progress^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Reopened')
    );
    finalEventLog.push(...reopenedEvents);

    // 11. Service Request Resolved
    const resolvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Resolved^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Resolved')
    );
    finalEventLog.push(...resolvedEvents);

    // 12. Service Request Closed
    const closedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalueINClosed Complete,Closed Incomplete,Closed Skipped^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Closed')
    );
    finalEventLog.push(...closedEvents);

    // 13. Request Rejected
    const rejectedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=rejected^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Rejected', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Rejected', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...rejectedEvents);

    // 14. Request Cancelled
    const cancelledEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Cancelled^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Cancelled')
    );
    finalEventLog.push(...cancelledEvents);

    // --- Write to CSV ---
    const csvStream = format({ headers: true });
    const writableStream = fs.createWriteStream('servicenow_event_log.csv');

    writableStream.on('finish', () => {
        console.log('CSV file written successfully.');
    });

    csvStream.pipe(writableStream);
    finalEventLog.sort((a, b) => new Date(a.EventTime) - new Date(b.EventTime)); // Sort events chronologically
    finalEventLog.forEach(row => csvStream.write(row));
    csvStream.end();
}

extractServiceRequestData();

¿Listo para comenzar?

Aproveche este Template para poner en marcha su iniciativa de Process Mining y conseguir mejoras significativas en la gestión de sus solicitudes de servicio. Empiece a optimizar sus flujos de trabajo hoy mismo para resolver las solicitudes más rápido y mejorar la satisfacción del cliente.

Volver a la guía de mejora Descargar Template

Transforme la gestión de solicitudes de servicio: actúe ahora

Alcance un 70 % de automatización y resuelva antes las solicitudes de servicio.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Configuración en 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 de informes y listas de ServiceNow a CSV/XLSX

Pasos

Configuración

a Consulta de ejemplo config

Script de Python con Requests para extraer datos mediante Table API

Pasos

Configuración

a Consulta de ejemplo python

Extracción de datos mediante ServiceNow REST Table API

Pasos

Configuración

a Consulta de ejemplo javascript

¿Listo para comenzar?

Transforme la gestión de solicitudes de servicio: actúe ahora

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 de informes y listas de ServiceNow a CSV/XLSX

Pasos

Configuración

a Consulta de ejemplo config

Script de Python con Requests para extraer datos mediante Table API

Pasos

Configuración

a Consulta de ejemplo python

Extracción de datos mediante ServiceNow REST Table API

Pasos

Configuración

a Consulta de ejemplo javascript

¿Listo para comenzar?

Transforme la gestión de solicitudes de servicio: actúe ahora

Valoramos su privacidad