> 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 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 Template de datos integral está diseñado para facilitar el análisis de Process Mining en la gestión de solicitudes de servicio. Ofrece indicaciones claras sobre los atributos esenciales que debe recopilar, las actividades clave que debe seguir y cómo extraer los datos de ServiceNow. Con este Template, podrá recopilar todos los datos necesarios para realizar un análisis preciso y optimizar el proceso de forma eficaz.

Atributos recomendados para recopilar
Actividades clave para descubrir el proceso
Guía paso a paso para extraer datos

¿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 su registro de eventos y analizar en profundidad el proceso de gestión de solicitudes de servicio.

5 Obligatorio 6 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento o la tarea específicos que se produjeron durante el ciclo de vida de la solicitud de servicio.
Descripción El atributo Actividad registra el nombre de cada paso o cambio de estado del proceso de solicitud de servicio. Puede incluir eventos como «Solicitud creada», «Solicitud aprobada», «Asignada a un agente» o «Solicitud cerrada». El análisis de estas actividades permite visualizar el flujo del proceso, identificar las rutas habituales y detectar desviaciones respecto del procedimiento estándar. Es la base para comprender lo que ocurre realmente durante la tramitación de las solicitudes. Por qué es importante Este es un atributo obligatorio que define los pasos del mapa del proceso. Es fundamental para todos los análisis de procesos, incluida la detección de cuellos de botella, ciclos de retrabajo y problemas de cumplimiento. Dónde obtenerlo Se obtiene 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 resueltaSe solicitó información a la persona usuaria
	Hora de inicio EventTime	Marca de tiempo que indica cuándo comenzó una actividad o un evento.
Descripción Este atributo registra la fecha y la hora exactas en que se produjo cada actividad del proceso de solicitud de servicio. Proporciona la secuencia cronológica de eventos necesaria para crear el mapa del proceso y realizar análisis basados en el tiempo. Las marcas de tiempo precisas son fundamentales para calcular los tiempos de ciclo, de espera y de procesamiento. Estos datos permiten detectar cuellos de botella, incumplimientos de los SLA y tendencias de rendimiento a lo largo del tiempo. Por qué es importante Esta marca de tiempo obligatoria permite ordenar correctamente los eventos. Es la base de todos los análisis de rendimiento y duración, incluidos el tiempo de ciclo y la detección de cuellos de botella. Dónde obtenerlo Suele encontrarse en los campos «sys_updated_on» o «sys_created_on» de las tablas pertinentes de ServiceNow (por ejemplo, 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 solicitud de servicio ServiceRequestID	Identificador único de cada registro de solicitud de servicio.
Descripción El ID de solicitud de servicio es la clave principal que identifica de forma única cada solicitud enviada por una persona usuaria o un sistema. Es el hilo conductor que vincula 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 todo su ciclo de vida. Por qué es importante Este es el ID del caso obligatorio. Vincula 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	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 sola fuente, este atributo aporta contexto importante y facilita la gobernanza y la gestión de los datos. Permite que cualquier persona comprenda el origen de los datos que analiza. 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 Suele ser un valor estático que se añade durante la extracción y transformación de los datos. Ejemplos ServiceNow
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la actualización o extracción de datos más reciente.
Descripción Este atributo indica la fecha y la hora en que se extrajeron por última vez los datos del sistema de origen y se cargaron en la herramienta de Process Mining. Permite saber si los datos analizados están actualizados. Quienes analizan los datos utilizan esta información para comprobar 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 la información obtenida. Por qué es importante Permite saber si los datos están actualizados, algo fundamental para confiar en el análisis y tomar decisiones oportunas basadas en datos. Dónde obtenerlo Este campo de metadatos se añade durante la ingesta de datos y refleja la marca de tiempo en que finalizó el proceso ETL. Ejemplos 2023-10-27T04:00:00Z
	Asignado a AssignedTo	Persona usuaria responsable de trabajar en la solicitud de servicio en un momento determinado.
Descripción Este atributo identifica a la persona agente o técnica específica asignada a la solicitud de servicio. Cambia cuando la solicitud pasa de una persona a otra. Analizar el campo «Asignado a» es fundamental para comprender cómo se distribuye la carga de trabajo, evaluar el rendimiento individual y medir el impacto de los traspasos en los tiempos de resolución. Permite responder preguntas sobre la utilización de los recursos y detectar 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 los traspasos entre agentes. Es esencial para gestionar los recursos y detectar cuellos de botella relacionados con personas específicas. 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	Clasificación principal de la solicitud de servicio, por ejemplo, hardware o software.
Descripción La categoría ofrece una clasificación general de la solicitud de servicio. Normalmente se utiliza para asignar la solicitud al equipo adecuado y elaborar informes sobre los tipos de solicitudes recibidas. En Process Mining, la categoría es una herramienta útil para filtrar y analizar los datos por dimensión. Permite comparar los flujos del proceso, los tiempos de ciclo y los niveles de automatización de distintos tipos de solicitudes, y descubrir variaciones que podrían pasar inadvertidas en los datos agregados. Por ejemplo, el proceso de una solicitud de «hardware» puede ser muy distinto del de una solicitud de «software». Por qué es importante Permite segmentar y comparar procesos de distintos tipos de servicio para identificar problemas específicos de cada categoría y oportunidades de mejora. Dónde obtenerlo Tabla Request Item de ServiceNow [sc_req_item], normalmente mediante la categoría del Catalog Item asociado [sc_cat_item]. Ejemplos HardwareSoftwareSolicitud de accesoRed
	Cumplió el SLA MadeSLA	Indicador booleano que señala si la solicitud de servicio se resolvió dentro del 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 resultados fundamental que mide directamente el desempeño del servicio frente a los compromisos establecidos. El análisis de este indicador permite calcular el KPI de cumplimiento del SLA. También puede utilizarse como dimensión para comparar las rutas del proceso de las solicitudes que cumplieron el SLA con las de aquellas que lo incumplieron, y así revelar patrones o actividades que suelen provocar incumplimientos. Esto es esencial para supervisar los riesgos de forma proactiva y mejorar continuamente el servicio. Por qué es importante Mide directamente el desempeño frente a los compromisos de servicio y permite analizar las causas raíz de los incumplimientos del SLA al comparar los casos que lo cumplieron con los que no. Dónde obtenerlo Tabla Task SLA de ServiceNow [task_sla], campo 'has_breached'. Es necesario invertir el valor (por ejemplo, MadeSLA = NOT has_breached). Ejemplos truefalse
	Estado State	Estado operativo actual de la solicitud de servicio.
Descripción El atributo Estado indica la etapa actual del ciclo de vida de la solicitud de servicio, como «Abierta», «En curso», «Pendiente» o «Cerrada». Los cambios en este campo suelen utilizarse para generar las actividades del mapa del proceso. Analizar el estado es fundamental para saber cuánto tiempo permanecen las solicitudes en estados específicos, sobre todo en los de espera o pendiente. Permite detectar colas y demoras, como el tiempo en «En espera de información de la persona usuaria», una causa habitual de ciclos prolongados. Por qué es importante Muestra el estado de la solicitud en cualquier momento y permite analizar los tiempos de espera, las colas y la duración de las distintas etapas del proceso. Dónde obtenerlo Tablas ServiceNow Request [sc_request] o Request Item [sc_req_item], campo «state» o «stage». Ejemplos AbiertoEn cursoA la espera de información del usuarioCerrado y completado
	Grupo de asignación AssignmentGroup	Equipo o grupo responsable de atender la solicitud de servicio.
Descripción El grupo de asignación representa al equipo responsable de una solicitud de servicio en una etapa determinada, como «Mesa de ayuda», «Operaciones de red» o «Administración de bases de datos». Es un atributo clave para analizar el flujo del proceso entre distintas áreas funcionales. Al hacer un seguimiento de los cambios en el grupo de asignación, las organizaciones pueden visualizar los traspasos entre equipos, medir los tiempos de espera en la cola de trabajo pendiente de cada grupo e identificar dependencias o demoras entre equipos. Esto es fundamental para optimizar la colaboración entre áreas. Por qué es importante Permite hacer un seguimiento de la distribución del trabajo entre equipos, destacar los traspasos entre ellos y detectar 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 ayudaSoporte de TI de nivel 2Aprovisionamiento de hardware
	Prioridad Priority	Nivel de prioridad de la solicitud de servicio, que determina su urgencia.
Descripción La prioridad clasifica la importancia y la urgencia relativas de una solicitud de servicio. Suele determinarse a partir de una combinación del impacto y la urgencia, y ayuda a los agentes a decidir qué solicitudes atender primero. Analizar los datos por prioridad es esencial para comprobar si las solicitudes de prioridad alta se tramitan más rápido que las de prioridad baja. Permite filtrar los Dashboards para verificar si se cumplen los SLA de las solicitudes críticas y determinar si el sistema de priorización es eficaz. Por qué es importante Permite segmentar las solicitudes y comprobar si los elementos de prioridad alta se tramitan 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ítico2 - Alto3 - Moderado4 - Bajo
	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 es la misma persona afectada por la solicitud, también puede ser un gerente, una persona delegada o un sistema automatizado. Analizar las solicitudes por usuario que las abrió o por su departamento ayuda a detectar patrones, como un grupo 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 solicitud por usuario, departamento o función, y 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	Método que utiliza quien solicita el servicio para enviar la solicitud.
Descripción El tipo de contacto, o canal, indica cómo se inició la solicitud de servicio. Entre los canales habituales se encuentran el portal de servicio, el correo electrónico, las llamadas telefónicas y las alertas automatizadas. Conocer el canal es importante para analizar las variaciones del proceso que pueden depender del método de envío. Por ejemplo, las solicitudes enviadas a través del portal pueden estar más estructuradas y automatizadas, por lo que se procesan más rápido que las recibidas por correo electrónico. Este análisis ayuda a fomentar el uso de 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, los niveles 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 llamarse 'contact_type'. Ejemplos PortalCorreo electrónicoTeléfonoAutoservicio
	Código de resolución ResolutionCode	Código que clasifica la resolución final de la solicitud de servicio.
Descripción El código de resolución clasifica de forma estructurada cómo se resolvió finalmente una solicitud de servicio. Algunos ejemplos son «Resuelto mediante automatización», «Error del usuario» o «Ya no es necesario». Este atributo es fundamental para el Dashboard de análisis de causas raíz de las demoras. Al relacionar los códigos de resolución con tiempos de ciclo prolongados o niveles elevados de retrabajo, quienes analizan los datos pueden identificar problemas sistémicos. Por ejemplo, si las solicitudes con el código «Información incompleta» tardan sistemáticamente en resolverse, puede haber un problema en la recopilación inicial de datos. Por qué es importante Proporciona datos estructurados sobre los resultados de las resoluciones y permite analizar las causas raíz de las demoras, el retrabajo y otras ineficiencias del proceso. Dónde obtenerlo Tabla Request Item [sc_req_item] de ServiceNow o una tabla de tareas relacionada; el campo suele llamarse 'close_code' o 'resolution_code'. Ejemplos Resuelto (de forma permanente)No resuelto (no se puede reproducir)Solicitud completadaCancelada por el usuario
	Es automatizado IsAutomated	Indicador que señala si un sistema o una automatización realizó una actividad.
Descripción Este atributo booleano distingue las actividades realizadas manualmente por una persona de las ejecutadas por un sistema automatizado, como un flujo de trabajo o una integración. Por ejemplo, «Solicitud de aprobación» puede ser una actividad automatizada, mientras que «Solicitud asignada a un agente» puede 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 más tiempo consumen y que podrían automatizarse en el futuro, lo que mejoraría la eficiencia y reduciría los costes. Por qué es importante Permite medir los niveles de automatización e identificar oportunidades para automatizar tareas manuales, aumentar la eficiencia y reducir 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 designado del sistema o de una integración. Ejemplos truefalse
	Es retrabajo IsRework	Indicador calculado que señala si una actividad repite otra actividad anterior del mismo caso.
Descripción Este indicador booleano permite detectar ciclos de retrabajo en una solicitud de servicio. Se marca como 'true' si la misma actividad ya se realizó antes en el mismo caso. Por ejemplo, si una solicitud se asigna dos veces al mismo equipo o si se pide información al usuario en varias ocasiones. Este atributo es esencial para el Dashboard de traspasos entre agentes e incidentes de retrabajo y para el KPI de tasa de retrabajo de solicitudes. Permite visualizar y cuantificar directamente los ciclos ineficientes del proceso, que suelen quedar 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 ciclos ineficientes que aumentan los costes y los tiempos de ciclo. Dónde obtenerlo Se calcula durante la transformación de datos, comprobando si el mismo nombre de actividad aparece antes en el mismo caso. Ejemplos falsetrue
	Hora de fin EndTime	Marca de tiempo que indica cuándo terminó una actividad o un evento.
Descripción La hora de fin marca la conclusión de una actividad. Corresponde a la marca de tiempo de la actividad siguiente en la secuencia y, por tanto, determina 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 fin de una actividad, se pueden calcular los tiempos de procesamiento y de espera. Esto es fundamental para detectar cuellos de botella, medir la eficiencia de los recursos y supervisar el rendimiento respecto de los objetivos de tiempo. Por qué es importante Este atributo es necesario para calcular la duración de cada actividad, un componente esencial del análisis del rendimiento, la detección de cuellos de botella y los estudios de utilización de recursos. Dónde obtenerlo Es un atributo derivado que se calcula a partir de «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 se ha reabierto una solicitud de servicio después de resolverse.
Descripción Este atributo cuenta cuántas veces una solicitud de servicio pasó de un estado resuelto o cerrado a uno abierto o en curso. Un valor superior a cero indica que la resolución inicial no tuvo éxito. Esta métrica indica directamente el retrabajo y es un componente clave del KPI de resolución en el primer intento. Un número elevado de reaperturas puede señalar problemas en la calidad de la resolución, una prestación incompleta del servicio 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 que proporciona quien solicita el servicio al cerrar la solicitud.
Descripción Este atributo recoge la puntuación de satisfacción, normalmente en una escala del 1 al 5, que envía el usuario final una vez resuelta su solicitud de servicio. Mide directamente la calidad del servicio percibida. Estos datos son esenciales para el Dashboard de análisis del impacto en la satisfacción del cliente. Permiten relacionar directamente las métricas del proceso, como el tiempo de ciclo, el retrabajo y los traspasos, con la experiencia final del cliente. Así se puede justificar la inversión en mejoras del proceso al vincular la eficiencia operativa con los resultados para el cliente. Por qué es importante Relaciona directamente las métricas de desempeño del proceso con los resultados para el cliente y ayuda a cuantificar el impacto de las ineficiencias en la experiencia del usuario. Dónde obtenerlo Suele encontrarse en una tabla Survey relacionada [asmt_assessment_instance], vinculada a la solicitud original. Ejemplos 5431
	Se resolvió en el primer intento IsFirstPassResolution	Indicador que señala si la solicitud se resolvió en el primer intento, sin reaperturas.
Descripción Este atributo calculado es un indicador booleano que solo tiene el valor 'true' si la solicitud de servicio se resolvió y cerró sin volver a abrirse. Es un indicador clave de la calidad y la eficacia de la resolución que ofrece la mesa de ayuda. Esta métrica contribuye directamente al KPI de tasa de resolución en el primer intento. Conviene que la tasa sea alta, ya que indica eficiencia y un servicio de calidad, lo que mejora la 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 en los clientes. Dónde obtenerlo Se calcula en el nivel del caso. Se considera que un caso se resolvió en el primer intento si su 'ReopenCount' es cero. Ejemplos truefalse
	Tiempo de ciclo del caso CaseCycleTime	Tiempo total transcurrido desde la creación de una solicitud de servicio hasta su cierre definitivo.
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 del último. Representa el tiempo de procesamiento completo de principio a fin desde la perspectiva del cliente. Es un indicador clave de desempeño (KPI) de la eficiencia general del proceso. Se utiliza en Dashboards de alto nivel para supervisar el desempeño frente a los objetivos y analizar las tendencias a lo largo del tiempo. También puede desglosarse por dimensiones, como la categoría o la prioridad, para identificar qué tipos de solicitudes tardan más. Por qué es importante Este KPI fundamental mide el desempeño integral del proceso. Es esencial para la supervisión de alto nivel, la comparación con valores de referencia y la identificación de oportunidades de mejora. Dónde obtenerlo Se calcula restando el valor mínimo de 'StartTime' al valor máximo de 'EndTime' para cada 'ServiceRequestID' único. Ejemplos 2 10:30:000 04:15:2210 00:05:00

Obligatorio Recomendado Opcional

Actividades de gestión de solicitudes de servicio

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

6 Recomendado 8 Opcional

	Actividad	Descripción
	Se solicitó información a la persona usuaria	Se produce cuando la persona agente encargada de la tramitación necesita más información de quien envió la solicitud para poder continuar. Por lo general, se infiere cuando el estado de la solicitud cambia a un valor como «En espera de información de la persona usuaria».
Por qué es importante Esta actividad es fundamental para el Dashboard «Análisis de las demoras por información de quien solicita», que permite cuantificar el tiempo perdido a la espera de información externa de la persona usuaria. Dónde obtenerlo Se infiere cuando el campo state de sc_req_item cambia a un estado designado de espera de información. El cambio se registra en la tabla sys_audit. Capturar Identifique la marca de tiempo en que sc_req_item.state cambia a «En espera de información de la persona usuaria». Tipo de evento inferred
	Solicitud aprobada	Esta actividad indica que la solicitud se ha aprobado oficialmente y puede pasar a la fase de tramitación. Se registra cuando la persona que aprueba marca como «Aprobado» el registro de aprobación correspondiente.
Por qué es importante Este hito clave marca el paso de la fase de aprobación a la de tramitación. Analizar cuánto se tarda en llegar a este punto es fundamental para comprender las demoras previas a la tramitación. Dónde obtenerlo Se infiere cuando el campo state del registro sysapproval_approver relacionado cambia a «Aprobado», lo que posteriormente provoca un cambio de estado en sc_req_item. Capturar Identifique la marca de tiempo en que sysapproval_approver.state pasa a «Aprobado». Tipo de evento inferred
	Solicitud asignada a un agente	Esta actividad se produce cuando se asigna a una persona agente específica la tarea de atender la solicitud de servicio. Se registra al supervisar los cambios en el campo «Asignado a» de la solicitud o de sus tareas de tramitación.
Por qué es importante Es fundamental para medir los traspasos, calcular la carga de trabajo de cada agente y analizar los tiempos de espera 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 la tabla sc_req_item o sc_task. El historial de cambios se registra en la tabla sys_audit. Capturar Realice un seguimiento de los cambios en el campo assigned_to en sys_audit. Tipo de evento inferred
	Solicitud de servicio cerrada	Marca el fin definitivo del ciclo de vida de la solicitud de servicio. Suele producirse automáticamente después de que la solicitud permanezca un tiempo determinado en el estado «Resuelta», durante el cual la persona usuaria puede volver a abrirla.
Por qué es importante Este es el evento de fin satisfactorio principal del proceso. También se puede analizar el tiempo entre «Resuelta» y «Cerrada» para comprender las políticas de cierre automático. Dónde obtenerlo Se infiere cuando el campo state de sc_req_item se actualiza a un estado final de cierre, como «Cerrada completa». Se registra en la tabla sys_audit. Capturar Identifique la marca de tiempo en que sc_req_item.state cambia a «Cerrada completa». 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 una persona usuaria envía una solicitud a través del catálogo de servicios. El sistema la registra como la 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 de ciclo total y analizar el volumen y los patrones de envío de solicitudes. Dónde obtenerlo Es un evento explícito que se obtiene de la marca de tiempo de creación (campo sys_created_on) del registro en la tabla sc_req_item. Capturar Use 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 encargada de la tramitación ha terminado el trabajo y ha proporcionado una solución. Se registra cuando el estado de la solicitud se actualiza a «Resuelta» o a uno similar.
Por qué es importante Es un hito fundamental que suele detener el cómputo del SLA. Marca el fin del trabajo activo de tramitación y es un componente clave para calcular el tiempo total de resolución. Dónde obtenerlo Se infiere cuando el campo state de sc_req_item se actualiza a «Resuelta» o a un estado terminal similar antes del cierre definitivo. El cambio se registra en la tabla sys_audit. Capturar Identifique la marca de tiempo en que sc_req_item.state cambia a «Resuelta». Tipo de evento inferred
	Aprobación solicitada	Indica el momento en que se envía una solicitud de servicio para que la apruebe una persona responsable o alguien designado para ello. Por lo general, se infiere cuando el estado de la solicitud cambia a «Pendiente de aprobación» o a un estado similar.
Por qué es importante El seguimiento de las aprobaciones permite detectar cuellos de botella en el proceso de aprobación y medir cuánto esperan las solicitudes la autorización antes de que pueda comenzar su tramitación. Dónde obtenerlo Se infiere cuando el campo state de sc_req_item cambia a un valor de aprobación pendiente o cuando se crea el registro correspondiente en la tabla sysapproval_approver. Los cambios se registran en la tabla sys_audit. Capturar Identifique la marca de tiempo en que sc_req_item.state cambia a «Pendiente de aprobación». Tipo de evento inferred
	La persona usuaria proporcionó la información	Esta actividad marca el momento en que quien envió la solicitud proporciona la información necesaria. Se infiere cuando la solicitud sale del estado «En espera de información de la persona usuaria» y vuelve a un estado activo, como «En curso».
Por qué es importante Al analizarla junto con «Se solicitó información a la persona usuaria», esta actividad permite medir con precisión las demoras causadas por la espera de información de la persona usuaria y evaluar la eficiencia de la comunicación. Dónde obtenerlo Se infiere cuando el campo state de sc_req_item cambia de un estado de espera de información a uno activo. A menudo, esto ocurre cuando la persona usuaria añade un comentario o responde a un correo electrónico. Capturar Identifique la marca de tiempo en que el estado cambia de «En espera de información de la persona usuaria» a «En curso». Tipo de evento inferred
	Proveedor externo involucrado	Representa el traspaso de una solicitud de servicio o de una de sus tareas a un proveedor externo para su tramitació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 desempeño del proveedor y su impacto en el ciclo de vida general de la solicitud. Es fundamental para el Dashboard «Ciclo de participación de proveedores externos». Dónde obtenerlo Por lo general, se infiere. Puede basarse en que assignment_group se asigne al grupo de un proveedor o en que se active un campo de marca específico en el registro sc_req_item o sc_task. Capturar 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 de tramitación específico. Este evento se infiere al detectar un cambio en el campo del grupo de asignación del elemento de solicitud o de las tareas asociadas.
Por qué es importante El seguimiento de las asignaciones a grupos permite analizar cómo se distribuye la carga de trabajo entre los equipos y detectar demoras antes de que la solicitud llegue al equipo de tramitación adecuado. Dónde obtenerlo Se infiere a partir de un cambio en el campo assignment_group de la tabla sc_req_item o sc_task. El historial de cambios se registra en la tabla sys_audit. Capturar Realice un seguimiento de los cambios en el campo assignment_group en sys_audit. Tipo de evento inferred
	Solicitud cancelada	Esta actividad marca el estado final de las solicitudes canceladas antes de completarse, ya sea por quien las envió o por una persona agente. Se registra cuando el estado de la solicitud pasa a «Cancelada» o «Cerrada por cancelación».
Por qué es importante Es un evento de fin clave que indica que el proceso no se completó con éxito. Analizar los motivos de cancelación puede aportar información sobre las necesidades de las personas usuarias, las ineficiencias del proceso o los cambios en las prioridades del negocio. Dónde obtenerlo Se infiere cuando el campo state de sc_req_item se actualiza a un estado final de cancelación, como «Cerrada por cancelación». El cambio se registra en la tabla sys_audit. Capturar Identifique la marca de tiempo en que sc_req_item.state cambia a «Cancelada». Tipo de evento inferred
	Solicitud reabierta	Esta actividad registra los casos en que una solicitud que se había marcado como resuelta vuelve a un estado abierto. Se infiere a partir de un cambio de estado de «Resuelta» a «En curso» o a uno similar.
Por qué es importante Es una medida directa del retrabajo y resulta fundamental para calcular el KPI «Tasa de resolución en el primer intento». Un valor alto indica que la solución es de baja calidad o que la resolución está incompleta. Dónde obtenerlo Se infiere a partir de un cambio en el campo state de sc_req_item, que pasa de un estado resuelto o cerrado a uno abierto o en curso. El cambio se registra en sys_audit. Capturar Detecte en sys_audit el cambio de estado de «Resuelta» a «En curso». Tipo de evento inferred
	Solicitud rechazada	Esta actividad representa el resultado de una solicitud que se rechaza formalmente durante la fase de aprobación. Es una ruta alternativa al cierre y se registra cuando la persona que aprueba marca la solicitud como «Rechazada».
Por qué es importante El seguimiento de los rechazos permite detectar solicitudes no válidas o mal dirigidas y problemas en el proceso de envío. También ofrece una ruta de excepción importante para el análisis. Dónde obtenerlo Se infiere cuando el campo state del registro sysapproval_approver relacionado cambia a «Rechazada». Por lo general, esto hace que el registro sc_req_item principal pase a un estado cerrado e incompleto. Capturar Identifique la marca de tiempo en que sysapproval_approver.state pasa a «Rechazada». Tipo de evento inferred
	Tarea de tramitación creada	Representa la creación de un elemento de trabajo o una tarea específicos necesarios para tramitar 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 tramitación y permite ver dónde se producen las demoras. Dónde obtenerlo Es un evento explícito que se obtiene 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. Capturar Use 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 estructura del modelo de datos de ServiceNow, una sola exportación no permite capturar todos los eventos necesarios. Debe exportar datos de varias tablas y luego combinar los archivos 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 las solicitudes 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 Número, Sys Created On, Resuelto, Cerrado, State, Assignment group, Assigned to 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 vincular las tareas 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 con sys_audit.list. Esta tabla contiene el historial de cambios en los 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. Es posible que necesite permisos elevados para acceder a esta tabla.
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 necesarias: ServiceRequestID, ActivityName y EventTime.
Asigne las actividades a los datos sin procesar: Cree una fila para cada actividad distinta. Por ejemplo:
- Para Service Request Created, use el valor de Sys Created On de la exportación de sc_req_item.
- Para Request Approved, use el valor de Sys Updated On de la exportación de sysapproval_approver cuando State haya cambiado a 'approved'.
- Para Request Assigned to Group, busque en la exportación de sys_audit la fila donde 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 en cada fila de actividad. Los valores deben reflejar el estado de la solicitud en el momento del evento.
Añada columnas de metadatos: Añada SourceSystem con un valor fijo, como 'ServiceNow', y LastDataUpdate con la fecha y hora en que realizó la extracción.
Finalice y exporte: Guarde los datos transformados y combinados en un único archivo CSV. Compruebe 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 cumplimiento generadas para una solicitud.
- sys_audit: proporciona un historial detallado de los cambios en los campos, esencial para hacer seguimiento de las asignaciones y los cambios de estado.
Filtro por intervalo de fechas: Es fundamental aplicar el mismo filtro de fechas, como Created on Last 6 months, en todas las exportaciones para garantizar la integridad de los datos. Se recomienda un periodo de 3 a 6 meses para equilibrar el volumen de datos y la información obtenida.
Filtros clave: Además del intervalo de fechas, utilice 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 pertinentes.
Columnas esenciales: Asegúrese de exportar identificadores clave, como Número y Sys ID (document key en la tabla de auditoría), para unir los conjuntos de datos. Las marcas de tiempo Sys Created On, Sys Updated On, Resuelto y Cerrado son fundamentales para crear el registro de eventos.
Requisitos previos: Para acceder a la mayoría de las tablas necesarias, se requiere una cuenta de usuario de ServiceNow con, al menos, el rol itil. La exportación de la tabla sys_audit puede requerir el rol admin u otro rol especializado debido al tamaño y la sensibilidad de los datos.

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: Compruebe que tenga instalado Python 3.6 o una versión posterior. 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 archivo. Introduzca la URL de su instancia de ServiceNow (por ejemplo, https://your-instance.service-now.com), un nombre de usuario y una contraseña de una cuenta de servicio con permisos de lectura adecuados para las tablas necesarias.
Defina el intervalo de fechas de extracción: Modifique las variables start_date y end_date para indicar las fechas de inicio y fin de la extracción. Se recomienda comenzar con un periodo más breve, por ejemplo, de 3 meses, para probar el script y comprobar su 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 la configuración de su instancia. Si utiliza tablas o campos personalizados, modifíquelos en el script.
Ejecute el script de Python: Ejecute el script desde la línea de comandos o la terminal con el comando python your_script_name.py. El script se conectará a la API de ServiceNow, obtendrá los datos de cada actividad especificada y mostrará el progreso en la consola.
Gestione la paginación de la API: El script incluye una función que gestiona la paginación automáticamente. Si el número de registros supera el límite por página (sysparm_limit), realizará varias llamadas a la API hasta recuperar todos los datos del intervalo 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 reúne en un único conjunto de datos.
Genere el archivo del registro de eventos: Al finalizar, el script guardará el registro de eventos en un archivo CSV llamado servicenow_servicerequest_eventlog.csv, en el mismo directorio desde el que se ejecutó.
Prepare los datos para cargarlos: Abra el archivo CSV generado en una hoja de cálculo y revise que los datos estén completos y sean correctos. Antes de cargarlo, compruebe que los encabezados de columna coincidan con el esquema requerido por ProcessMind.

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 necesita el nombre de usuario y la 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: Configure 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áginas (sysparm_limit): El script establece un límite para el número de registros devueltos en cada llamada a la API. El valor predeterminado es 1000, una cifra adecuada para la mayoría de las instancias. Puede ajustarlo según el rendimiento del sistema y los límites de solicitudes de la API.
Filtros de consulta (sysparm_query): El script utiliza filtros de fecha (sys_created_on>=...) para limitar los datos extraídos. Puede añadir otros filtros a la cadena de consulta, por ejemplo, para seleccionar un elemento de catálogo o un grupo de asignación específico y reducir el volumen de datos (active=true^category=hardware).
Valores de visualización: El parámetro sysparm_display_value=true permite obtener nombres legibles para los campos de referencia en lugar de los valores internos sys_id. Esto es fundamental para atributos como AssignmentGroup y AssignedTo.

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

Configure un usuario de API en ServiceNow: Cree un usuario específico para esta integración en su instancia de ServiceNow. Asígnele los roles rest_service e itil. Compruebe que tenga permisos de lectura (ACL) para las siguientes tablas: Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver) y Audit (sys_audit).
Prepare el entorno de desarrollo: Instale Node.js en el equipo que utilizará para la extracción. A continuación, inicialice un proyecto de Node.js e instale las bibliotecas axios, para realizar solicitudes HTTP, y fast-csv, para escribir el archivo de salida. Ejecute npm install axios fast-csv en la terminal.
Configure 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.
Defina 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 filtros a las cadenas sysparm_query de cada actividad para limitar el alcance, por ejemplo, seleccionando un elemento de catálogo o un grupo de asignación específico.
Comprenda las llamadas a la API: El script realiza llamadas a la API por separado para cada una de las 14 actividades necesarias. Consulta directamente las tablas de origen (sc_req_item, sc_task) para obtener eventos como la creación, y la tabla sys_audit para registrar cambios de estado y asignaciones mediante actualizaciones de campos específicos.
Ejecute el script: Ejecútelo desde la terminal con el comando node extract.js. El script se conectará a ServiceNow Table API, obtendrá los datos de cada actividad y gestionará la paginación automáticamente.
Procese los datos: A medida que los reciba, el script transformará la respuesta JSON de ServiceNow a un formato estándar de registro de eventos y asignará los campos a columnas como ServiceRequestID, ActivityName y EventTime.
Combine y consolide los resultados: El script reúne los resultados de todas las llamadas individuales a la API en una única matriz que representa el registro de eventos completo.
Genere el archivo de salida: Cuando se hayan obtenido y procesado todos los datos, el script utilizará la biblioteca fast-csv para guardar el registro de eventos consolidado en un archivo llamado servicenow_event_log.csv, en el mismo directorio.
Prepare los datos para cargarlos: El archivo CSV generado ya tiene las columnas necesarias para Process Mining. No es necesario darle otro formato antes de cargarlo en la plataforma ProcessMind.

Configuración

URL de la instancia de ServiceNow: URL base de su entorno de ServiceNow, por ejemplo, https://your-instance.service-now.com.
Credenciales de la API: Nombre de usuario y contraseña válidos de un usuario de ServiceNow con los permisos de lectura y los roles necesarios (rest_service, itil).
Intervalo de fechas: Se recomienda extraer datos de un periodo de 3 a 6 meses para obtener un conjunto representativo. Configure las variables startDate y endDate del script; sus valores se aplican a los campos de marca de tiempo correspondientes en las consultas a la API.
sysparm_query: Es el parámetro principal de la URL 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 'Resuelto' a 'En curso'.
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 ya incluye los campos necesarios para cada consulta.
Límite de paginación (sysparm_limit): El script está configurado para obtener registros en lotes de 1000. Puede modificar este valor, pero se recomienda no superar el máximo de ServiceNow, que suele ser 10.000, para mantener la estabilidad.

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

¿Todo listo para comenzar?

Utilice esta plantilla para poner en marcha su iniciativa de Process Mining e impulsar mejoras importantes en la gestión de solicitudes de servicio. Empiece hoy mismo a optimizar sus flujos de trabajo para resolver las solicitudes más rápido y mejorar la satisfacción de los clientes.

Volver a la guía de mejora

Descargar Template

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

Logre un 70 % de automatización y resuelva las solicitudes de servicio más rápido.

Comience su prueba gratuita

No se requiere 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 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

Consulta de ejemplo config

Script de Python con Requests para extraer datos mediante Table API

Pasos

Configuración

Consulta de ejemplo python

Extracción de datos mediante ServiceNow REST Table API

Pasos

Configuración

Consulta de ejemplo javascript

¿Todo listo para comenzar?

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