> Mejora continua de procesos > Gestión de solicitudes de servicio > BMC Helix ITSM > Template de datos

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

BMC Helix ITSM

Atributos de la gestión de solicitudes de servicio (20) 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

Esta plantilla ofrece una visión clara de los atributos de datos esenciales que debe recopilar y de las actividades clave que debe supervisar en su proceso de gestión de solicitudes de servicio. También incluye orientación práctica para extraer estos datos de forma eficiente desde BMC Helix ITSM. Utilice este recurso para agilizar la preparación de sus datos e iniciar sus iniciativas de process mining con confianza.

Atributos recomendados para recopilar
Actividades clave que debe supervisar
Guía de extracción para BMC Helix ITSM

¿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 campos de datos son esenciales para crear un registro de eventos completo y realizar un análisis profundo de su proceso de gestión de solicitudes de servicio.

5 Obligatorio 6 Recomendado 9 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre del evento o la tarea específicos que ocurrieron en un momento determinado del ciclo de vida de la solicitud de servicio.
Descripción Este atributo describe un paso específico o un cambio de estado en el proceso de solicitud de servicio, como «Request In Review», «Fulfillment In Progress» o «Service Request Resolved». Cada actividad representa un único evento en el recorrido completo de una solicitud de servicio. Analizar la secuencia y la frecuencia de las actividades es el núcleo del Process Mining. Permite descubrir mapas de procesos, identificar cuellos de botella y analizar variantes del proceso. Comprender qué actividades ocurren, en qué orden y con qué frecuencia es fundamental para optimizar el proceso. Por qué es importante Las actividades son los elementos básicos del mapa de procesos. Hacerles seguimiento permite visualizar y analizar el flujo del proceso, y revela cómo se realiza realmente el trabajo. Dónde obtenerlo Normalmente, se deriva de los cambios en los campos «Status» y «Status Reason» del formulario «SRM:Request» o de los registros de aplicaciones de cumplimiento relacionadas, como Incident o Work Order. Ejemplos Solicitud en espera de aprobaciónCumplimiento en cursoSolicitud de servicio resueltaSolicitud de servicio cerrada
	Hora de inicio EventStartTime	La marca de tiempo que indica cuándo comenzó una actividad o un evento específicos.
Descripción Este atributo registra la fecha y hora exactas en que comenzó una actividad. Cada evento del registro, desde el envío inicial hasta el cierre final, debe tener una hora de inicio para establecer la secuencia cronológica del proceso. Esta marca de tiempo es fundamental para todos los análisis de Process Mining basados en el tiempo. Se utiliza para calcular los tiempos de ciclo, la duración de las actividades y los tiempos de espera entre pasos, así como para comprobar el cumplimiento del SLA. Permite descubrir cuellos de botella y analizar el rendimiento del proceso a lo largo del tiempo. Por qué es importante La hora de inicio proporciona el orden cronológico de los eventos, algo esencial para calcular la duración del proceso, identificar retrasos y comprender su línea temporal. Dónde obtenerlo Corresponde a los campos de marca de tiempo de los registros de auditoría o las tablas de historial de estados asociadas al formulario «SRM:Request», como «Submit Date» para el evento inicial. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ID de la solicitud de servicio ServiceRequestId	El identificador único de cada solicitud de servicio, que actúa como clave principal para hacer seguimiento de todo su ciclo de vida.
Descripción El Service Request ID identifica de forma única cada solicitud de servicio individual enviada por un usuario o sistema. Actúa como hilo conductor central que vincula todos los eventos posteriores, desde el registro inicial hasta el cierre final, y permite analizar de principio a fin el recorrido de cada solicitud de servicio. En Process Mining, este ID es fundamental para reconstruir la secuencia de actividades de cada caso. Permite agrupar todos los eventos relacionados, como «Request Submitted», «Request Assigned» y «Service Request Closed», en una única instancia de proceso, que constituye la base de todo análisis del proceso. Por qué es importante Este es el identificador fundamental del caso. Sin él, no es posible rastrear el recorrido completo de una solicitud de servicio, por lo que el descubrimiento y el análisis del proceso resultarían imposibles. Dónde obtenerlo Normalmente, corresponde al campo «InstanceId» o «Request Number» del formulario «SRM:Request» en BMC Helix ITSM. Ejemplos SR000010572931SR000010572932SR000010572933
	Sistema de origen SourceSystem	Identifica el sistema del que se extrajeron los datos.
Descripción Este atributo especifica el origen de los datos del proceso. En esta vista, se establecería de forma estática en «BMC Helix ITSM» para indicar que todos los eventos relacionados con las solicitudes de servicio proceden de este sistema. En entornos con varios sistemas integrados, este campo es fundamental para comprender el linaje de los datos y particionarlos según su origen. Garantiza claridad y trazabilidad, especialmente al combinar datos de distintas plataformas. Por qué es importante Proporciona contexto sobre el origen de los datos, algo importante para la gobernanza de datos, la trazabilidad y la resolución de problemas en entornos con varios sistemas. Dónde obtenerlo Es un valor estático que se añade durante el proceso de extracción y transformación de datos, no un campo propio de BMC Helix ITSM. Ejemplos BMC Helix ITSM
	Última actualización de datos LastDataUpdate	La marca de tiempo en la que se actualizaron por última vez los datos de este proceso desde el sistema de origen.
Descripción Este atributo indica la fecha y hora de la extracción de datos más reciente desde BMC Helix ITSM. Proporciona contexto sobre la actualidad de los datos analizados y permite conocer el periodo que abarca el análisis. Es un atributo de metadatos fundamental para cualquier panel o análisis de Process Mining. Permite saber si los insights se basan en datos casi en tiempo real o en una instantánea histórica, lo que afecta a la validez y la relevancia de las conclusiones obtenidas. Por qué es importante Informa sobre la actualidad de los datos, algo esencial para tomar decisiones basadas en la información más reciente disponible sobre el rendimiento del proceso. Dónde obtenerlo Esta marca de tiempo se genera y se añade durante el proceso de extracción y carga de datos. Ejemplos 2024-05-21T08:00:00Z
	Equipo asignado AssignedTeam	El grupo o equipo de soporte asignado actualmente a la solicitud de servicio.
Descripción Este atributo identifica al grupo funcional responsable de gestionar la solicitud, como «Mesa de ayuda», «Equipo de redes» o «Administración de bases de datos». Un cambio en este campo indica una transferencia de responsabilidad entre equipos. El análisis basado en el equipo asignado ayuda a identificar cuellos de botella a nivel de equipo, analizar los traspasos entre equipos y evaluar la eficiencia de los distintos grupos de soporte. Es clave para los Dashboards de reprocesamiento y reasignación de solicitudes y de eficiencia del triaje, ya que revela patrones sobre cómo se distribuye el trabajo en la organización. Por qué es importante Permite analizar el flujo del proceso entre distintos grupos funcionales, ayuda a identificar ineficiencias de enrutamiento y permite medir el rendimiento a nivel de equipo. Dónde obtenerlo Corresponde al campo «Assigned Group» del registro de cumplimiento, como Work Order o Incident, asociado a la solicitud de servicio. Ejemplos Mesa de serviciosSoporte de infraestructuraSoporte de aplicaciones de nivel 2
	Estado de la solicitud RequestStatus	El estado de la solicitud de servicio en el momento del evento, como «In Progress», «Pending» o «Closed».
Descripción Este atributo captura el estado de la solicitud de servicio en distintos momentos de su ciclo de vida. El estado proporciona contexto para cada actividad y suele ser el origen del que se deriva el propio atributo «Activity». Analizar por estado ayuda a comprender cuánto tiempo pasan las solicitudes en determinados estados, como «Pending Customer» o «Waiting for Approval». Esto es fundamental para identificar cuellos de botella y retrasos causados por dependencias externas o colas internas. Es compatible directamente con el panel Bottleneck Identification. Por qué es importante Proporciona una instantánea del estado de la solicitud y permite analizar el tiempo dedicado a estados de espera frente a estados activos, algo clave para identificar cuellos de botella. Dónde obtenerlo Es el campo «Status» del formulario «SRM:Request». Los valores históricos pueden consultarse en el registro de auditoría. Ejemplos PlanificaciónEn cursoPendienteResueltoCerrado
	Hora de finalización EventEndTime	La marca de tiempo que indica cuándo se completó una actividad o un evento específicos.
Descripción La hora de finalización marca la conclusión de una actividad. Aunque muchas actividades de los sistemas ITSM son cambios de estado instantáneos, algunas tienen una duración medible. Contar con una hora de finalización permite calcular con precisión la duración de esas actividades. En el análisis, la hora de finalización se utiliza junto con la hora de inicio para calcular el tiempo de procesamiento de cada actividad. Esto ayuda a identificar qué tareas concretas, y no solo los tiempos de espera entre ellas, consumen más tiempo en el proceso. Por qué es importante Permite calcular los tiempos de procesamiento de las actividades, algo fundamental para identificar pasos ineficientes y comprender dónde emplean su tiempo los recursos. Dónde obtenerlo Puede derivarse. La hora de finalización de una actividad suele ser la hora de inicio de la siguiente actividad secuencial del mismo caso. Para la actividad final, correspondería a la marca de tiempo de resolución o cierre. Ejemplos 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Persona agente asignada AssignedAgent	La persona usuaria asignada actualmente para trabajar en la solicitud de servicio.
Descripción Este atributo identifica a la persona agente de TI o de soporte responsable de la solicitud en un momento determinado. Los cambios en este campo durante el ciclo de vida de una solicitud indican una transferencia o reasignación. Este atributo es fundamental para analizar el rendimiento y la carga de trabajo de las personas agentes. Permite hacer seguimiento del número de solicitudes que gestiona cada persona, su tiempo medio de resolución y la frecuencia de las reasignaciones. Estos datos respaldan la gestión de recursos y la identificación de oportunidades de capacitación. Por qué es importante Hacer seguimiento de la persona agente asignada es fundamental para analizar las transferencias, medir el rendimiento individual y comprender la distribución de la carga de trabajo en el equipo de soporte. Dónde obtenerlo Corresponde al campo «Assignee» o «Assigned To» del registro de cumplimiento, como Work Order o Incident, asociado a la solicitud de servicio. Ejemplos Bob SmithAlice JohnsonCharlie Brown
	Prioridad Priority	El nivel de prioridad asignado a la solicitud de servicio, que indica su impacto empresarial y urgencia.
Descripción La prioridad determina el orden y la rapidez con que deben gestionarse las solicitudes. Los valores habituales incluyen «Crítico», «Alto», «Medio» y «Bajo». Esta asignación suele basarse en una combinación del impacto de la solicitud en el negocio y su urgencia. Analizar por prioridad es esencial para evaluar si las solicitudes de alta prioridad se procesan más rápido que las de baja prioridad. Es una dimensión clave en los Dashboards de tiempo de resolución y cumplimiento de SLA, ya que ayuda a garantizar que los recursos se asignen adecuadamente a las necesidades empresariales más críticas. Por qué es importante Ayuda a evaluar si el proceso prioriza correctamente el trabajo y cumple los niveles de servicio esperados para solicitudes con distintos niveles de impacto empresarial. Dónde obtenerlo Es el campo «Priority» del formulario «SRM:Request». Ejemplos CríticaAltaMediaBaja
	Tipo de servicio ServiceType	La categoría o el tipo de servicio solicitado por el usuario.
Descripción El tipo de servicio clasifica la naturaleza de la solicitud, por ejemplo, «Solicitar software nuevo», «Restablecer contraseña» o «Incorporar a una persona empleada nueva». Es una dimensión fundamental para filtrar y segmentar los datos del proceso. En el análisis de procesos, este atributo se utiliza para comparar el rendimiento de distintos tipos de solicitudes. Ayuda a responder preguntas como «¿Qué tipos de servicio tardan más en resolverse?» o «¿Qué tipos de servicio requieren más reprocesamiento?». Es fundamental para los Dashboards de tiempo de resolución y cumplimiento de SLA. Por qué es importante Permite segmentar las solicitudes de servicio para comparar los flujos del proceso, identificar problemas específicos de cada tipo y adaptar eficazmente las iniciativas de optimización. Dónde obtenerlo Estos datos suelen encontrarse en el campo «Title» o en un campo de categorización del formulario «SRM:Request», derivado del servicio seleccionado en el catálogo. Ejemplos Solicitud de hardware nuevoSolicitud de acceso al softwareConfiguración del acceso VPN
	Canal de envío SubmissionChannel	El método o canal a través del cual se envió la solicitud de servicio.
Descripción Este atributo registra cómo se inició la solicitud de servicio, por ejemplo, mediante un portal de autoservicio, correo electrónico, una llamada telefónica a la mesa de servicio o una alerta automática del sistema. Los distintos canales pueden dar lugar a variantes del proceso y tiempos de resolución diferentes. Analizar el proceso por canal de envío puede revelar ineficiencias o buenas prácticas asociadas a métodos específicos de recepción. Por ejemplo, las solicitudes enviadas a través del portal de autoservicio pueden resolverse más rápido gracias a una mejor calidad inicial de los datos, mientras que las recibidas por correo electrónico pueden requerir una clasificación más manual. Por qué es importante Ayuda a comprender cómo afecta el método de recepción a la eficiencia del proceso, la calidad de los datos y el tiempo de ciclo general, y permite aplicar mejoras específicas en determinados canales. Dónde obtenerlo A menudo puede inferirse a partir de campos como «Client Type» o «Reported Source» del formulario «SRM:Request» o de los tickets de cumplimiento asociados. Ejemplos Portal de autoservicioCorreo electrónicoTeléfonoGenerado por el sistema
	Categoría de resolución ResolutionCategory	La clasificación de la solución proporcionada para resolver la solicitud.
Descripción Este atributo proporciona una categorización estructurada de la forma en que se resolvió una solicitud, como «Software Fix», «User Training» o «Data Correction». Va más allá de un simple código de cierre, ya que describe la naturaleza de la resolución. Es fundamental para el panel Resolution Category Accuracy, donde puede compararse con el tipo de servicio inicial para comprobar la coherencia. Analizar las categorías de resolución ayuda a identificar tendencias en los problemas y orienta la gestión proactiva de problemas, por ejemplo, si muchas solicitudes se resuelven mediante capacitación del usuario. Por qué es importante Ofrece información sobre la naturaleza de las soluciones y ayuda a identificar tendencias en problemas recurrentes y oportunidades para gestionar problemas de forma proactiva o capacitar a los usuarios. Dónde obtenerlo Esta información forma parte de los campos de categorización operativa y de producto del ticket de cumplimiento, que a menudo se denominan «Resolution Category». Ejemplos Administración de cuentasFallo de hardwareActualización de softwareInformación proporcionada
	Código de cierre CloseCode	Un código que indica el resultado final o el motivo del cierre de la solicitud de servicio.
Descripción El código de cierre proporciona una forma estandarizada de clasificar la resolución de una solicitud de servicio. Algunos ejemplos son «Resolved by Service Desk», «Canceled by User» o «Duplicate Request». Analizar los códigos de cierre ayuda a comprender los resultados habituales de las solicitudes. Puede poner de manifiesto problemas como un número elevado de solicitudes canceladas por los usuarios, lo que podría indicar un proceso demasiado largo, o muchas solicitudes duplicadas, lo que podría apuntar a un problema del sistema o de comunicación. Este atributo respalda el panel Resolution Category Accuracy. Por qué es importante Proporciona datos estructurados sobre los resultados de las solicitudes y permite analizar la eficacia de la resolución y los motivos de la no finalización o cancelación. Dónde obtenerlo Esta información suele encontrarse en un campo «Resolution» o «Closure Code» del ticket de cumplimiento asociado a la solicitud de servicio. Ejemplos CorrectoCancelado por el usuarioYa no es necesarioResolución automatizada
	Departamento de quien realizó la solicitud RequestorDepartment	El departamento o la unidad de negocio de la persona usuaria que envió la solicitud.
Descripción Este atributo identifica el departamento organizativo de la persona que solicita el servicio, como «Finance», «Human Resources» o «IT». Esta información suele obtenerse del perfil de usuario del sistema. Segmentar el análisis del proceso por departamento permite identificar necesidades específicas, patrones de solicitudes y posibles áreas para capacitación específica o mejoras del servicio. También ayuda a responder preguntas como «¿El departamento de Finance experimenta tiempos de espera más largos en sus solicitudes?». Por qué es importante Permite analizar el consumo de servicios y el rendimiento del proceso por unidad de negocio, lo que puede poner de manifiesto problemas o tendencias específicos de cada departamento. Dónde obtenerlo Esta información suele obtenerse del perfil de la persona usuaria asociada al usuario «Requested For» del formulario «SRM:Request». Ejemplos FinanzasVentasRecursos humanosTecnologías de la información
	Es retrabajo IsRework	Indicador booleano que señala si una solicitud de servicio ha pasado por un retrabajo, como volver a una etapa anterior.
Descripción Este indicador identifica las solicitudes de servicio que han experimentado un bucle o retrabajo en su flujo de proceso. Por ejemplo, una solicitud que pasa de «Fulfillment in Progress» a «Request in Review» se consideraría retrabajo. La definición exacta depende de la lógica del proceso empresarial. Este atributo respalda directamente el Dashboard de análisis de retrabajos y reasignaciones de solicitudes y el KPI de tasa de retrabajo de solicitudes. Permite cuantificar la frecuencia del retrabajo y analizar sus causas habituales, como una evaluación inicial incorrecta o información incompleta, que generan ineficiencias en el proceso. Por qué es importante Cuantifica la ineficiencia del proceso al señalar los casos que se desvían de la «ruta ideal», lo que ayuda a identificar las causas raíz de los bucles y del trabajo repetido. Dónde obtenerlo Es un atributo calculado derivado de la secuencia de actividades del registro de eventos. Se necesita lógica para detectar movimientos hacia atrás en el flujo del proceso. Ejemplos truefalse
	Está escalada IsEscalated	Indicador booleano que señala si la solicitud de servicio se ha escalado.
Descripción Este indicador se establece en true si una solicitud de servicio ha pasado por una escalación funcional o jerárquica. Normalmente, una escalación se produce cuando una solicitud no avanza según lo previsto, está a punto de incumplir un SLA o requiere la intervención de una autoridad superior para su aprobación o gestión. Este atributo es clave para el Dashboard de análisis de la eficiencia de las escalaciones de solicitudes. Permite filtrar y analizar las rutas de proceso de las solicitudes escaladas para comprender qué las desencadena, cuánto tardan en resolverse después de la escalación y qué tan eficaz es el proceso de escalación. Por qué es importante Permite aislar y analizar el subconjunto de solicitudes que requirieron una escalación, lo que ayuda a identificar debilidades en el proceso estándar o factores desencadenantes de problemas complejos. Dónde obtenerlo Normalmente no corresponde a un único campo. Se obtiene comprobando actividades específicas relacionadas con escalaciones en el registro de auditoría, o cambios de prioridad o asignación posteriores a un protocolo de escalación. Ejemplos truefalse
	Fecha objetivo del SLA SlaTargetDate	La fecha y hora en las que se espera resolver la solicitud de servicio según su Acuerdo de Nivel de Servicio (SLA).
Descripción La fecha objetivo del SLA es una marca de tiempo calculada que representa el plazo límite para completar la solicitud de servicio. Se determina según las reglas del acuerdo de servicio, que suelen tener en cuenta factores como la prioridad y el tipo de solicitud. Este atributo es fundamental para el panel SLA Compliance Overview. Sirve como referencia para medir el tiempo real de resolución. Al comparar el «EventEndTime» de la actividad final de resolución con esta fecha objetivo, podemos determinar si se cumplió el compromiso de servicio. Por qué es importante Es la referencia principal para medir el rendimiento del servicio frente a los compromisos, por lo que resulta esencial para supervisar y comunicar el cumplimiento del SLA. Dónde obtenerlo Esta fecha la calcula y almacena el módulo Service Level Management (SLM) y puede encontrarse en los formularios de SLM relacionados y vinculados a la solicitud de servicio. Ejemplos 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	Número de transferencias HandoffCount	Número total de veces que una solicitud de servicio se reasignó entre distintos agentes o equipos.
Descripción Esta métrica calculada cuenta cuántas veces cambian «AssignedAgent» o «AssignedTeam» para una misma solicitud de servicio. Un número elevado de transferencias puede indicar fragmentación del proceso, falta de resolución en el primer contacto o un enrutamiento ineficiente. Este atributo es la base del KPI de promedio de transferencias entre agentes por solicitud y se utiliza en el Dashboard de retrabajos y reasignaciones de solicitudes. Analizar los casos con un número elevado de transferencias puede revelar oportunidades para mejorar la clasificación inicial, ofrecer una mejor capacitación o agilizar el proceso de resolución, reducir las demoras y mejorar la satisfacción del cliente. Por qué es importante Mide la fragmentación del proceso y la sobrecarga de comunicación. Un número elevado de transferencias suele correlacionarse con tiempos de resolución más largos y una menor eficiencia del proceso. Dónde obtenerlo Es una métrica calculada que se obtiene contando el número de valores distintos del atributo «AssignedAgent» o «AssignedTeam» para cada ID único de solicitud de servicio. Ejemplos 0135
	Se incumplió el SLA IsSlaBreached	Indicador booleano que señala si la solicitud de servicio se resolvió después de la fecha objetivo de su SLA.
Descripción Este indicador calculado se establece en true si la marca de tiempo de la resolución final de la solicitud de servicio es posterior a su «SLA Target Date». Proporciona un resultado binario sencillo sobre el rendimiento del SLA para cada solicitud. Este atributo es esencial para el Dashboard de visión general del cumplimiento de SLA y el KPI de tasa de cumplimiento de SLA. Permite agregar fácilmente los datos para calcular las tasas generales de cumplimiento y filtrarlos para analizar las características del proceso de las solicitudes que incumplieron el SLA frente a las que lo cumplieron, lo que ayuda a identificar las causas raíz de los incumplimientos. Por qué es importante Simplifica el análisis del rendimiento del SLA al convertir una comparación de marcas de tiempo en un indicador booleano sencillo, lo que facilita medir y visualizar las tasas de cumplimiento. Dónde obtenerlo Es un campo calculado. La lógica es: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Ejemplos truefalse

Obligatorio Recomendado Opcional

Actividades de la gestión de solicitudes de servicio

Estos pasos clave y estos hitos del proceso deben capturarse en su registro de eventos para descubrir y visualizar el proceso con precisión.

6 Recomendado 8 Opcional

	Actividad	Descripción
	Cumplimiento en curso	La persona agente o el equipo asignado ha comenzado a trabajar activamente en el cumplimiento de la solicitud de servicio. Esto indica que la solicitud ha pasado de una cola a un estado de trabajo activo.
Por qué es importante Marca el inicio del trabajo de cumplimiento que aporta valor. Analizar el tiempo dedicado a esta fase ayuda a comprender la productividad de los recursos y la complejidad del cumplimiento. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «In Progress». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «In Progress». Tipo de evento inferred
	Solicitud asignada	La solicitud de servicio se ha asignado a una persona agente o a un equipo específico responsable de completar el trabajo. Esto marca el final de la fase de clasificación.
Por qué es importante Este hito es fundamental para medir el tiempo de clasificación y analizar la carga de trabajo de las personas agentes. Las reasignaciones frecuentes pueden indicar problemas de enrutamiento o carencias de habilidades. Dónde obtenerlo Este evento puede capturarse explícitamente en el registro de auditoría de los campos «Assigned Group» o «Assignee» de SRM:Request o de los formularios de aplicaciones de cumplimiento relacionados, por ejemplo, WOI:WorkOrder. Recopilar Marca de tiempo del registro de auditoría que muestra la primera asignación de un valor no nulo al campo «Assignee». Tipo de evento explicit
	Solicitud de servicio cancelada	La solicitud de servicio ha sido retirada por quien la realizó o por la mesa de servicio antes de completar el cumplimiento. Este es un estado terminal de la solicitud.
Por qué es importante El seguimiento de las cancelaciones ayuda a identificar patrones, como el envío de solicitudes incorrectas o servicios que ya no son necesarios, lo que puede orientar las mejoras del catálogo de servicios. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Canceled». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «Canceled». Tipo de evento inferred
	Solicitud de servicio cerrada	La solicitud de servicio se cierra formalmente y pasa a un estado archivado de solo lectura. Esto ocurre después de la resolución y una vez transcurrido cualquier periodo de confirmación.
Por qué es importante Esta actividad representa el final definitivo del proceso. El tiempo entre «Resolved» y «Closed» puede poner de manifiesto ineficiencias en el procedimiento de cierre. Dónde obtenerlo Se infiere a partir del cambio de estado final del formulario SRM:Request a «Closed». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «Closed». Tipo de evento inferred
	Solicitud de servicio enviada	Esta actividad marca la creación y el envío de una nueva solicitud de servicio por parte de un usuario. Se registra cuando se crea una nueva entrada en el formulario SRM:Request con un estado inicial, normalmente «Submitted».
Por qué es importante Este es el punto de partida de cada solicitud de servicio, fundamental para medir la duración total de su ciclo de vida y analizar el volumen de solicitudes recibidas. Dónde obtenerlo Este evento se infiere a partir de la marca de tiempo de creación y del estado inicial, por ejemplo, «Submitted», de un registro del formulario SRM:Request. Recopilar Identifique la marca de tiempo de creación de un nuevo Service Request ID en el formulario SRM:Request cuando el estado sea «Submitted». Tipo de evento inferred
	Solicitud de servicio resuelta	El cumplimiento de la solicitud de servicio ha finalizado y la resolución se ha comunicado a quien realizó la solicitud. La solicitud espera la confirmación final o se cerrará automáticamente después de un periodo establecido.
Por qué es importante Un hito fundamental que marca el final del ciclo de prestación del servicio. Es el punto final principal para medir el tiempo de resolución y el cumplimiento del SLA. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Resolved» o «Completed». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «Resolved» o «Completed». Tipo de evento inferred
	Información solicitada al usuario	La persona agente encargada del cumplimiento necesita información adicional de quien realizó la solicitud para continuar con el trabajo. Normalmente, la solicitud pasa al estado «Pending».
Por qué es importante Esta actividad es fundamental para calcular el «External Information Wait Time» e identificar con qué frecuencia las solicitudes se detienen por falta de información. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Pending», con un motivo de estado como «Customer Hold» o «Awaiting Information». Recopilar Marca de tiempo del cambio de estado a «Pending» combinada con un motivo de estado específico. Tipo de evento inferred
	Resolución confirmada por el usuario	Quien realizó la solicitud ha confirmado activamente que el servicio se prestó de forma satisfactoria y que la solicitud está resuelta. Esto suele activar el cierre final de la solicitud.
Por qué es importante Proporciona un indicador claro de la satisfacción del cliente y concluye formalmente la interacción de servicio. Distingue la resolución del proceso de la aceptación por parte del cliente. Dónde obtenerlo Este evento puede capturarse en los registros de trabajo o las notas de actividad de SRM:Request cuando un usuario confirma a través del portal o por correo electrónico. No siempre corresponde a un estado independiente. Recopilar Revise los registros de trabajo (SRM:WorkInfo) en busca de entradas específicas que indiquen la confirmación del usuario o la finalización de una encuesta. Tipo de evento explicit
	Solicitud aprobada	La solicitud de servicio ha sido aprobada formalmente por la persona o entidad requerida, lo que permite continuar con el proceso de cumplimiento. Este evento suele producirse después del estado «Waiting for Approval».
Por qué es importante Marca el final del subproceso de aprobación y es un hito clave para hacer seguimiento de la duración de las aprobaciones y su impacto en el tiempo total de resolución. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request de «Waiting Approval» a un estado posterior como «Planning» o «In Progress». La decisión de aprobación se registra en los formularios de aprobación relacionados. Recopilar Marca de tiempo del cambio de estado desde «Waiting Approval» después de una decisión de aprobación positiva. Tipo de evento inferred
	Solicitud en espera de aprobación	La solicitud de servicio se ha enviado a una persona aprobadora o a un grupo de aprobación designado y está a la espera de una decisión antes de que pueda comenzar su cumplimiento. Este es un paso habitual en las solicitudes que implican costos o derechos de acceso.
Por qué es importante Esta actividad aísla los retrasos relacionados con la aprobación, lo que permite analizar los tiempos del ciclo de aprobación e identificar cuellos de botella en la cadena de aprobación. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a un valor como «Waiting Approval». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «Waiting Approval». Tipo de evento inferred
	Solicitud en revisión	La solicitud de servicio está siendo revisada y clasificada inicialmente por la mesa de servicio para determinar su naturaleza, prioridad y equipo de cumplimiento adecuado. Normalmente, esto se representa mediante un cambio de estado en el registro de la solicitud.
Por qué es importante El seguimiento de esta actividad ayuda a medir la eficiencia de la clasificación e identificar retrasos entre el envío y la asignación, algo fundamental para el KPI «Average Triage Time». Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a un valor como «In Review» o «Planning». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «In Review». Tipo de evento inferred
	Solicitud reanudada	La solicitud de servicio ha salido de un estado pendiente o de espera, normalmente después de que el usuario haya proporcionado la información requerida. La persona agente encargada del cumplimiento reanuda el trabajo en la solicitud.
Por qué es importante Marca el final de un periodo de espera y permite medir con precisión los tiempos de espera externos y su impacto en el cumplimiento del SLA. Dónde obtenerlo Se infiere cuando el estado de SRM:Request cambia de «Pending» a «In Progress». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia de «Pending» a «In Progress». Tipo de evento inferred
	Solicitud rechazada	La solicitud de servicio fue denegada durante una fase de aprobación. Este es un estado terminal que detiene el proceso antes de que comience el cumplimiento.
Por qué es importante Analizar las solicitudes rechazadas puede poner de manifiesto problemas relacionados con la justificación de las solicitudes, los criterios de elegibilidad o las políticas de aprobación. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Rejected». Recopilar Marca de tiempo del evento de actualización en el que el campo «Status» de SRM:Request cambia a «Rejected». Tipo de evento inferred
	Solución implementada	La persona agente ha completado el trabajo técnico necesario para cumplir la solicitud de servicio. La solicitud está lista para que el usuario la confirme antes de resolverse formalmente.
Por qué es importante Esta actividad separa la finalización técnica de la resolución formal y ayuda a identificar los retrasos entre la finalización del trabajo y la confirmación del usuario. Dónde obtenerlo Puede inferirse a partir de un cambio de estado en un ticket de cumplimiento del backend, por ejemplo, cuando el estado de Work Order cambia a «Completed», antes de que la SRM:Request principal se marque como «Resolved». Recopilar Marca de tiempo en la que un ticket del backend, como Work Order o Incident, vinculado a SRM:Request se marca como completado. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de BMC Helix ITSM

Pasos

Acceda a Smart Reporting: Inicie sesión en su entorno de BMC Helix ITSM. Vaya a la sección de informes e inicie Smart Reporting. Según su versión, puede aparecer como «Reports» o «Smart Reporting».
Cree un informe nuevo: En la interfaz de Smart Reporting, seleccione la opción para crear un informe nuevo. Elija «Report» como tipo.
Seleccione la fuente de datos y la vista: Se le pedirá que seleccione una fuente de datos. Elija su fuente de datos principal de AR System. Para la vista, busque y seleccione la vista Service Request, que normalmente se basa en el formulario SRM:Request.
Añada formularios adicionales (uniones): Para capturar todo el ciclo de vida, debe unir el formulario principal SRM:Request con los formularios relacionados. Use la pestaña «Data» y añada las siguientes uniones:
- SRM:WorkInfo (mediante SR ID+ = Request Number) para obtener detalles sobre las actividades de resolución y los registros de trabajo.
- AP:Signature (mediante Request = SRInstanceID) para obtener eventos relacionados con las aprobaciones, como aprobaciones y rechazos. Es posible que necesite una unión personalizada.
Defina las columnas del informe: Arrastre los campos necesarios de los formularios unidos al área «Columns». Incluya campos como Request Number, Submit Date, Estado, Descripción, Priority, Assigned To y Assigned Group de SRM:Request, además de los campos relacionados de los formularios unidos.
Cree campos calculados para las actividades: El elemento central de este método consiste en crear una serie de campos calculados que representen la marca de tiempo de cada actividad. Vaya a la pestaña «Data» y cree un campo calculado nuevo para cada actividad. Por ejemplo:
- Marca de tiempo de envío: Use directamente el campo Submit Date.
- Marca de tiempo de aprobación: Use Signature Date del formulario AP:Signature.
- Marca de tiempo de trabajo en curso: Use MIN(Submit Date) de SRM:WorkInfo, agrupado por Request Number.
Estructure el informe para la unión: Smart Reporting no tiene un botón «UNION ALL» sencillo como SQL. Para lograrlo, cree un único informe y use funciones avanzadas o subconsultas para dinamizar los datos. Una técnica habitual consiste en crear varias columnas calculadas, una para la marca de tiempo de cada actividad. Después, deberá dar formato a la exportación final para transformar estas columnas en filas independientes para cada actividad.
Aplique filtros: Para limitar el alcance de los datos y mejorar el rendimiento, añada filtros al informe. Como mínimo, filtre por Submit Date del formulario SRM:Request para seleccionar un intervalo de fechas concreto. Añada también filtros para «Company» si trabaja en un entorno multiinquilino.
Ejecute el informe y previsualice los datos: Ejecute el informe para comprobar que los datos se recuperan correctamente. Verifique las uniones, las columnas rellenadas y que los campos calculados devuelvan las marcas de tiempo esperadas.
Exporte el informe: Cuando haya validado el informe, exporte los datos. Elija CSV o Microsoft Excel como formato de exportación, ya que ambos se procesan fácilmente para importarlos en herramientas de Process Mining.
Transforme los datos finales: Después de exportarlos, debe transformar los datos de un formato ancho (una fila por solicitud de servicio con muchas columnas de marcas de tiempo) a un formato largo (una fila por actividad). Use un script, por ejemplo, Python o PowerShell, o una herramienta como Excel Power Query para dinamizar las columnas de marcas de tiempo y convertirlas en dos columnas: ActivityName y EventStartTime. Este paso es fundamental para crear la estructura necesaria del registro de eventos.

Configuración

Requisitos previos: Debe tener una cuenta de usuario con permisos de generación de informes en BMC Helix ITSM, incluido el acceso para crear y ejecutar informes en Smart Reporting. También necesita permisos para leer datos de los formularios SRM:Request, SRM:WorkInfo y AP:Signature.
Formularios clave: El informe se crea uniendo estos formularios principales:
- SRM:Request: formulario principal que contiene los detalles básicos de la solicitud de servicio.
- SRM:WorkInfo: contiene entradas del registro de trabajo, que se utilizan para derivar las actividades de atención.
- AP:Signature: contiene registros de aprobación, esenciales para supervisar las actividades relacionadas con aprobaciones.
Filtrado por intervalo de fechas: Aplique siempre un filtro de intervalo de fechas al campo SRM:Request.Submit Date. Se recomienda un intervalo de 3 a 6 meses para equilibrar la obtención de una muestra representativa y el rendimiento del informe.
Filtros importantes: Además del intervalo de fechas, filtre por Company para aislar los datos de una entidad empresarial concreta. También puede excluir tipos de solicitud o estados específicos, como «Draft», que no sean relevantes para el análisis del proceso.
Consideraciones de rendimiento: Los informes que unen varios formularios en un intervalo de fechas amplio pueden tardar en generarse. Para grandes volúmenes de datos, se recomienda programar el informe fuera de las horas punta. Si se producen tiempos de espera agotados, considere dividir la extracción en bloques mensuales más pequeños.

a Consulta de ejemplo sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Pasos

Requisitos previos: Asegúrese de tener un cliente de base de datos, como DBeaver, SQL Server Management Studio u Oracle SQL Developer, y credenciales de solo lectura para la base de datos de BMC Helix AR System.
Conéctese a la base de datos: Utilice su cliente de base de datos para establecer una conexión con el servidor de la base de datos de AR System.
Prepare la consulta: Copie la consulta SQL completa proporcionada en la sección «Query» de este documento en el editor de consultas de su cliente de base de datos.
Establezca los parámetros: Localice los valores de marcador de posición de la consulta. Sustituya :start_date y :end_date por el intervalo de fechas deseado para la extracción, por ejemplo, «2023-01-01» y «2023-12-31». Sustituya :company_name por el nombre de la empresa que desea utilizar como filtro, si corresponde.
Ejecute la consulta: Ejecute la consulta SQL modificada. Según el intervalo de fechas y el tamaño del sistema, el proceso puede tardar varios minutos.
Revise los resultados: Cuando termine la consulta, aparecerá un conjunto de resultados que contiene el registro de eventos. Revise brevemente los datos para comprobar que se hayan cargado correctamente y que incluyan las columnas y actividades esperadas.
Gestione las marcas de tiempo: Compruebe que todas las columnas de marcas de tiempo, específicamente EventStartTime, EventEndTime y LastDataUpdate, tengan un formato coherente, como «YYYY-MM-DD HH:MI:SS». Si la base de datos las devuelve en otro formato, ajuste las funciones TO_CHAR o CONVERT de la consulta según corresponda.
Exporte los datos: Utilice la función de exportación de su cliente de base de datos para guardar todo el conjunto de resultados como archivo CSV. Elija la codificación UTF-8 para garantizar la compatibilidad.
Prepare la carga: Asigne al archivo un nombre adecuado, por ejemplo, servicerequest_eventlog.csv. El archivo ya estará listo para cargarse en la plataforma ProcessMind.

Configuración

Credenciales de la base de datos: Se necesita una cuenta de usuario de solo lectura para la base de datos de AR System. Esto evita modificaciones accidentales de los datos y cumple las buenas prácticas de seguridad.
Filtrado por intervalo de fechas: La consulta incluye los marcadores de posición :start_date y :end_date. Es fundamental establecer un intervalo de fechas concreto y razonable, normalmente de 3 a 12 meses de datos, para controlar el rendimiento de la consulta y el volumen de datos. El filtro se aplica a Submit_Date de la solicitud de servicio.
Filtro de empresa: Se incluye el marcador de posición :company_name para filtrar las solicitudes de una empresa operativa concreta. Si necesita extraer datos de todas las empresas, puede eliminar la línea AND req.Company = :company_name o establecer un comodín, si se admite.
Valores de estado: La consulta utiliza valores enteros de estado estándar de BMC Helix ITSM, por ejemplo, Submitted = 0, In Review = 1, etc. Su sistema puede tener estados personalizados o asignaciones enteras diferentes. Verifique estos valores en el formulario SYS:Status o en Developer Studio de su sistema y ajuste las cláusulas WHERE de la consulta si es necesario.
Rendimiento: Las consultas directas a tablas grandes, como SRM_Request y sus registros de auditoría, pueden consumir muchos recursos. Programe la extracción fuera de las horas punta para minimizar el impacto en el rendimiento del sistema.

a Consulta de ejemplo sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Pasos

Requisitos previos: Asegúrese de tener Python 3.6 o una versión posterior instalada en su sistema. Instale la biblioteca requests, necesaria para realizar llamadas a la API HTTP, ejecutando pip install requests en su terminal o símbolo del sistema.
Obtenga las credenciales de la API: Cree u obtenga las credenciales de una cuenta de servicio específica en BMC Helix ITSM. Esta cuenta necesita al menos permisos de solo lectura para el formulario SRM:Request y el formulario de registro de auditoría correspondiente, que suele llamarse SRM:Request_AuditLog o algo similar. Anote su nombre de usuario, contraseña y la URL base de su instancia de BMC Helix, por ejemplo, https://[your-company].bmc.com.
Configure el script de Python: Copie el script de Python proporcionado en un archivo, por ejemplo, extract_servicerequests.py. Edite el script y complete las variables de marcador de posición de la parte superior: BASE_URL, USERNAME, PASSWORD y AUDIT_FORM_NAME. Ajuste el diccionario STATUS_ACTIVITY_MAP para que coincida con los valores de estado específicos utilizados en el Workflow de solicitudes de servicio de su organización.
Establezca el periodo de extracción: Modifique las variables START_DATE y END_DATE del script. Esto define el intervalo temporal de la extracción según la fecha de envío de la solicitud de servicio. Para las pruebas iniciales, utilice un intervalo pequeño, como un solo día.
Ejecute el script: Ejecute el script desde su terminal mediante el comando python extract_servicerequests.py. Primero, el script se autenticará en la API para obtener un token.
Obtención inicial de datos: El script consulta el formulario SRM:Request para recuperar una lista de todas las solicitudes de servicio creadas dentro del intervalo de fechas especificado. Este paso recopila el ID del caso y atributos estáticos asociados, como la prioridad y el tipo de servicio.
Obtenga el historial de eventos: El script recorre cada ID de solicitud de servicio obtenido en el paso anterior. Para cada ID, realiza una segunda llamada a la API al formulario de registro de auditoría configurado para obtener el historial detallado de cambios de estado de esa solicitud.
Transforme los datos en un registro de eventos: Para cada registro del registro de auditoría, el script asigna el cambio de estado a un nombre de actividad estándar mediante STATUS_ACTIVITY_MAP. Crea una fila para cada actividad asignada, con el ID de la solicitud de servicio, el nombre de la actividad y la marca de tiempo del cambio.
Genere el evento de envío: El script también crea la actividad inicial «Service Request Submitted» para cada solicitud, utilizando Submit Date del formulario principal SRM:Request.
Exporte a CSV: Después de procesar todas las solicitudes de servicio y sus historiales, el script consolida las filas generadas en una única lista y escribe los datos en un archivo CSV llamado servicerequest_event_log.csv. Este archivo queda preparado para cargarse en una herramienta de process mining.

Configuración

Endpoints de la API: El script utiliza principalmente dos endpoints de la API. La autenticación se gestiona mediante api/jwt/login. Los datos se consultan desde arsys/v1/entry/SRM:Request para obtener la lista de casos y desde arsys/v1/entry/[AUDIT_FORM_NAME] para obtener el historial de eventos.
Permisos de la cuenta de servicio: Se necesita una cuenta de servicio específica con acceso de lectura al formulario SRM:Request y al formulario de registro de auditoría del sistema. Utilizar una cuenta de servicio es fundamental para la seguridad y la trazabilidad.
Filtrado por intervalo de fechas: El script está configurado para filtrar las solicitudes de servicio según su Submit Date. Se recomienda extraer los datos en lotes manejables, por ejemplo, de 3 a 6 meses cada vez, para garantizar un rendimiento fiable.
Asignación de estados a actividades: El diccionario STATUS_ACTIVITY_MAP del script es el núcleo de la lógica de transformación. Debe configurarse cuidadosamente para reflejar los estados personalizados de su organización y asignarlos a los nombres de actividad deseados. Se ignorará cualquier estado del Workflow que no esté incluido en el mapa.
Formulario de registro de auditoría: La capacidad del script para capturar actividades detalladas depende por completo de que exista un registro de auditoría consultable. Debe identificar el nombre correcto del formulario de su entorno que almacena el historial de cambios de estado de las solicitudes de servicio y actualizar la variable AUDIT_FORM_NAME en consecuencia.
Paginación: El script gestiona automáticamente la paginación de la API para recuperar todos los registros. El parámetro limit de la llamada a la API está configurado para recuperar 1.000 registros por solicitud, con el fin de equilibrar el rendimiento y el uso de memoria.

a Consulta de ejemplo python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

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

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

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

¿Listo para comenzar?

Utilice esta plantilla para agilizar la recopilación de sus datos e iniciar su recorrido de process mining con confianza. ¡Comience hoy mismo a optimizar la gestión de sus solicitudes de servicio!

Volver a la guía de mejora Descargar Template

Libere eficiencia: optimice hoy la gestión de solicitudes de servicio

Alcance un 70 % de automatización, elimine las demoras en la atención y ofrezca una experiencia excelente a los usuarios.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Comience en cuestión de 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

Informes inteligentes de BMC Helix ITSM para solicitudes de servicio

Pasos

Configuración

a Consulta de ejemplo sql

Consulta SQL directa en las tablas de la base de datos de AR System

Pasos

Configuración

a Consulta de ejemplo sql

Extracción mediante un script de Python a través de la API REST de BMC Helix

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Libere eficiencia: optimice hoy la gestión de solicitudes de servicio

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

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

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

Informes inteligentes de BMC Helix ITSM para solicitudes de servicio

Pasos

Configuración

a Consulta de ejemplo sql

Consulta SQL directa en las tablas de la base de datos de AR System

Pasos

Configuración

a Consulta de ejemplo sql

Extracción mediante un script de Python a través de la API REST de BMC Helix

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Libere eficiencia: optimice hoy la gestión de solicitudes de servicio

Valoramos su privacidad