> 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 gestión de solicitudes de servicio(20) 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 ofrece una visión clara de los atributos de datos esenciales que debe recopilar y de las actividades clave que debe seguir en el proceso de gestión de solicitudes de servicio. También incluye indicaciones prácticas para extraer estos datos de BMC Helix ITSM de forma eficiente. Utilice este recurso para agilizar la preparación de los datos y poner en marcha sus iniciativas de Process Mining con confianza.

Atributos recomendados para recopilar
Actividades clave que debe seguir
Indicaciones para extraer datos de BMC Helix ITSM

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

Descargar Template

Atributos de gestión de solicitudes de servicio

Estos campos de datos son esenciales para crear un registro de eventos completo y analizar en profundidad el proceso de gestión de solicitudes de servicio.

5 Obligatorio 6 Recomendado 9 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento o la tarea específicos que tuvieron lugar en un momento determinado del ciclo de vida de la solicitud de servicio.
Descripción Este atributo describe un paso concreto o un cambio de estado en el proceso de solicitud de servicio, como «Solicitud en revisión», «Atención en curso» o «Solicitud de servicio resuelta». Cada actividad representa un evento del recorrido completo de una solicitud de servicio. Analizar la secuencia y la frecuencia de las actividades es la base de Process Mining. Esto 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 los procesos. Por qué es importante Las actividades son los componentes básicos del mapa de procesos. Hacer un seguimiento de ellas permite visualizar y analizar el flujo del proceso para descubrir cómo se realiza realmente el trabajo. Dónde obtenerlo Suele obtenerse a partir de los cambios en los campos «Status» y «Status Reason» del formulario «SRM:Request» o de los registros de aplicaciones relacionadas con la atención, como Incident o Work Order. Ejemplos Solicitud pendiente de aprobaciónAtención en cursoSolicitud de servicio resueltaSolicitud de servicio cerrada
	Hora de inicio EventStartTime	Marca de tiempo que indica cuándo comenzó una actividad o un evento específicos.
Descripción Este atributo registra la fecha y la hora exactas en que comenzó una actividad. Cada evento del registro, desde el envío inicial hasta el cierre definitivo, debe tener una hora de inicio para establecer el orden cronológico 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 de los SLA. También permite descubrir cuellos de botella y analizar el rendimiento del proceso a lo largo del tiempo. Por qué es importante La hora de inicio establece el orden cronológico de los eventos, algo esencial para calcular la duración de los procesos, identificar demoras y comprender su cronología. Dónde obtenerlo Corresponde a los campos de marca de tiempo de los registros de auditoría o las tablas del historial de estados asociados 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	Identificador único de cada solicitud de servicio, que sirve como clave principal para hacer un seguimiento de todo su ciclo de vida.
Descripción El ID de la solicitud de servicio identifica de forma única cada solicitud individual que presenta un usuario o un sistema. Es el vínculo central que conecta todos los eventos posteriores, desde el registro inicial hasta el cierre definitivo, y permite analizar de principio a fin el recorrido de cada solicitud. En Process Mining, este ID es esencial para reconstruir la secuencia de actividades de cada caso. Permite agrupar todos los eventos relacionados, como «Solicitud enviada», «Solicitud asignada» y «Solicitud de servicio cerrada», en una sola instancia del proceso, que sirve de base para todo análisis del proceso. Por qué es importante Este es el identificador fundamental del caso. Sin él, no es posible seguir de principio a fin el recorrido de una solicitud de servicio, por lo que tampoco se pueden descubrir ni analizar los procesos. Dónde obtenerlo Suele corresponder 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 como «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 la procedencia de los datos y segmentarlos según su origen. Aporta claridad y trazabilidad, especialmente al combinar datos de distintas plataformas. Por qué es importante Aporta 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 la extracción y transformación de los datos; no es un campo propio de BMC Helix ITSM. Ejemplos BMC Helix ITSM
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la última actualización de los datos de este proceso desde el sistema de origen.
Descripción Este atributo indica la fecha y la hora de la extracción más reciente de datos de BMC Helix ITSM. Informa sobre la actualidad de los datos analizados y permite saber qué período abarca el análisis. Es un metadato fundamental para cualquier Dashboard o análisis de Process Mining. Permite saber si las conclusiones se basan en datos casi en tiempo real o en una instantánea histórica, lo que influye en su validez y pertinencia. Por qué es importante Informa sobre la actualidad de los datos, algo esencial para tomar decisiones con 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 la extracción y carga de los datos. Ejemplos 2024-05-21T08:00:00Z
	Agente asignado AssignedAgent	Usuario asignado actualmente para atender la solicitud de servicio.
Descripción Este atributo identifica al agente de TI o miembro del equipo de soporte responsable de la solicitud en un momento determinado. Los cambios en este campo durante el ciclo de vida de una solicitud indican un traspaso o una reasignación. Este atributo es fundamental para analizar el rendimiento de los agentes y la distribución de la carga de trabajo. Permite hacer un seguimiento del número de solicitudes que gestiona cada agente, su tiempo medio de resolución y la frecuencia de las reasignaciones. Estos datos ayudan a gestionar los recursos e identificar oportunidades de formación. Por qué es importante Hacer un seguimiento del agente asignado es esencial para analizar los traspasos, medir el rendimiento individual y comprender cómo se distribuye la carga de trabajo en el equipo de soporte. Dónde obtenerlo Corresponde al campo «Assignee» o «Assigned To» del registro de cumplimiento (por ejemplo, Work Order o Incident) asociado a la solicitud de servicio. Ejemplos Bob SmithAlice JohnsonCharlie Brown
	Equipo asignado AssignedTeam	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 que la responsabilidad se ha transferido a otro equipo. El análisis por equipo asignado ayuda a identificar cuellos de botella en cada equipo, analizar los traspasos entre equipos y evaluar la eficiencia de los distintos grupos de soporte. Es clave para los Dashboards de Análisis de retrabajo y reasignación de solicitudes y Eficiencia de clasificación, ya que permite detectar patrones en la distribución del trabajo en la organización. Por qué es importante Permite analizar el flujo del proceso entre distintos grupos funcionales, identificar ineficiencias en el enrutamiento y medir el rendimiento de cada equipo. Dónde obtenerlo Corresponde al campo «Assigned Group» del registro de cumplimiento (por ejemplo, Work Order o Incident) asociado a la solicitud de servicio. Ejemplos Mesa de ayudaSoporte de infraestructuraSoporte de aplicaciones de nivel 2
	Estado de la solicitud RequestStatus	Estado de la solicitud de servicio en el momento del evento, como «En curso», «Pendiente» o «Cerrada».
Descripción Este atributo registra el estado de la solicitud de servicio en distintos momentos de su ciclo de vida. El estado aporta contexto a cada actividad y suele ser el origen del propio atributo «Actividad». Analizar los datos por estado permite saber cuánto tiempo permanecen las solicitudes en determinados estados, como «Pendiente del cliente» o «En espera de aprobación». Esto es esencial para identificar cuellos de botella y demoras causados por dependencias externas o colas internas. Además, sirve de apoyo directo al Dashboard de identificación de cuellos de botella. Por qué es importante Muestra el estado de la solicitud en un momento determinado y permite comparar el tiempo en espera con el tiempo en actividad, algo clave para identificar cuellos de botella. Dónde obtenerlo Es el campo «Status» del formulario «SRM:Request». Los valores históricos se encuentran en el registro de auditoría. Ejemplos PlanificaciónEn cursoPendienteResueltaCerrada
	Hora de finalización EventEndTime	Marca de tiempo que indica cuándo se completó una actividad o un evento específicos.
Descripción La hora de finalización marca el cierre 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 esa duración con precisión. 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 las esperas 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 en qué se emplean los recursos. Dónde obtenerlo Puede calcularse. La hora de finalización de una actividad suele coincidir con la hora de inicio de la siguiente actividad 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
	Prioridad Priority	Nivel de prioridad asignado a la solicitud de servicio, que indica su impacto en el negocio y su urgencia.
Descripción La prioridad determina el orden y la rapidez con que deben atenderse las solicitudes. Entre los valores habituales están «Crítica», «Alta», «Media» y «Baja». Suele asignarse según una combinación del impacto de la solicitud en el negocio y su urgencia. Analizar los datos 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 los SLA, ya que ayuda a garantizar que los recursos se asignen adecuadamente a las necesidades más críticas del negocio. 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 en el negocio. Dónde obtenerlo Es el campo «Priority» del formulario «SRM:Request». Ejemplos CríticaAltaMediaBaja
	Tipo de servicio ServiceType	Categoría o 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 un empleado nuevo». Es una dimensión fundamental para filtrar y segmentar los datos del proceso. En el análisis de procesos, este atributo permite 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 generan más retrabajo?». Es fundamental para los Dashboards de tiempo de resolución y cumplimiento de los SLA. Por qué es importante Permite segmentar las solicitudes de servicio para comparar los flujos de proceso, identificar problemas específicos de cada tipo y orientar 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», y se derivan del servicio seleccionado en el catálogo. Ejemplos Solicitud de hardware nuevoSolicitud de acceso a softwareConfiguración de acceso a VPN
	Canal de envío SubmissionChannel	Método o canal por el que se envió la solicitud de servicio.
Descripción Este atributo registra cómo se inició la solicitud de servicio, por ejemplo, a través de un portal de autoservicio, por correo electrónico, mediante una llamada a la mesa de ayuda o a partir de una alerta automatizada del sistema. Los distintos canales pueden dar lugar a variantes del proceso y a diferentes tiempos de resolución. Analizar el proceso según el canal de envío puede revelar ineficiencias o buenas prácticas asociadas a determinados métodos 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 quizá requieran más clasificación manual. Por qué es importante Ayuda a comprender cómo influye el método de recepción en la eficiencia del proceso, la calidad de los datos y el tiempo de ciclo general, y permite introducir mejoras específicas en cada canal. Dónde obtenerlo A menudo, esta información puede deducirse 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	Clasificación de la solución proporcionada para resolver la solicitud.
Descripción Este atributo clasifica de forma estructurada cómo se resolvió una solicitud, por ejemplo, mediante una «Corrección de software», «Formación del usuario» o «Corrección de datos». Va más allá de un simple código de cierre, ya que describe la naturaleza de la resolución. Es esencial para el Dashboard de Precisión de la categoría de resolución, donde se puede comparar 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, permite detectar si muchas solicitudes se resuelven mediante formación de usuarios. Por qué es importante Aporta 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 formar 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 suelen llevar la etiqueta «Resolution Category». Ejemplos Administración de cuentasFallo de hardwareActualización de softwareInformación proporcionada
	Código de cierre CloseCode	Código que indica el resultado final o el motivo del cierre de la solicitud de servicio.
Descripción El código de cierre ofrece una forma estandarizada de clasificar la resolución de una solicitud de servicio. Algunos ejemplos son «Resuelta por la mesa de ayuda», «Cancelada por el usuario» o «Solicitud duplicada». Analizar los códigos de cierre ayuda a comprender los resultados más 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 que el proceso es demasiado largo, o muchas solicitudes duplicadas, que podrían apuntar a un problema del sistema o de comunicación. Este atributo sirve de base para el Dashboard de Precisión de la categoría de resolución. Por qué es importante Proporciona datos estructurados sobre los resultados de las solicitudes, lo que permite analizar la eficacia de las resoluciones y los motivos por los que no se completaron o se cancelaron. 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 Resuelta correctamenteCancelada por el usuarioYa no se necesitaResolución automatizada
	Departamento de quien solicita RequestorDepartment	Departamento o unidad de negocio de la persona que envió la solicitud.
Descripción Este atributo identifica el departamento de la persona que solicita el servicio, como «Finanzas», «Recursos Humanos» o «TI». Por lo general, esta información se obtiene del perfil de usuario en el sistema. Segmentar el análisis del proceso por departamento permite identificar necesidades y patrones de solicitud específicos, así como posibles oportunidades de formación o mejora del servicio. También ayuda a responder preguntas como «¿El departamento de Finanzas tiene que esperar más para recibir respuesta a 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 asociada al usuario «Requested For» en el formulario «SRM:Request». Ejemplos FinanzasVentasRecursos HumanosTecnología de la información
	Es retrabajo IsRework	Indicador booleano que señala si una solicitud de servicio ha requerido retrabajo, por ejemplo, al volver a una etapa anterior.
Descripción Este indicador identifica las solicitudes de servicio que han pasado por un bucle o han requerido retrabajo en el flujo del proceso. Por ejemplo, si una solicitud pasa de «Cumplimiento en curso» a «Solicitud en revisión», se considera que ha habido retrabajo. La definición exacta depende de la lógica del proceso de negocio. Este atributo sirve directamente de base para el Dashboard de Análisis de retrabajo y reasignación 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 las ineficiencias del proceso al señalar los casos que se desvían de la ruta ideal. Así, ayuda a identificar las causas raíz de los bucles y del trabajo repetido. Dónde obtenerlo Es un atributo calculado a partir de la secuencia de actividades del registro de eventos. Se necesita una lógica que detecte los retrocesos en el flujo del proceso. Ejemplos truefalse
	Fecha objetivo del SLA SlaTargetDate	Fecha y hora en que se espera resolver la solicitud de servicio, según el acuerdo de nivel de servicio (SLA).
Descripción La fecha objetivo del SLA es una marca de tiempo calculada que indica la fecha 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 Dashboard de Resumen de cumplimiento del SLA. Sirve como referencia para medir el tiempo real de resolución. Al comparar «EventEndTime» de la actividad de resolución final con esta fecha objetivo, se puede 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 adquiridos, por lo que resulta esencial para supervisar y presentar informes sobre el cumplimiento del SLA. Dónde obtenerlo Esta fecha la calcula y almacena el módulo de Gestión de niveles de servicio (SLM). Puede consultarse 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 traspasos 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» en una misma solicitud de servicio. Un número elevado de traspasos puede indicar fragmentación del proceso, falta de resolución en el primer contacto o un enrutamiento ineficiente. Este atributo sirve de base para el KPI de número medio de traspasos por solicitud y se utiliza en el Dashboard de Análisis de retrabajo y reasignación de solicitudes. Analizar los casos con muchos traspasos puede revelar oportunidades para mejorar la clasificación, ofrecer más formació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 el esfuerzo de coordinación. Un número elevado de traspasos suele estar relacionado con tiempos de resolución más largos y una menor eficiencia del proceso. Dónde obtenerlo Es una métrica calculada que cuenta los valores distintos del atributo «AssignedAgent» o «AssignedTeam» para cada ID de solicitud de servicio único. Ejemplos 0135
	Se ha escalado IsEscalated	Indicador booleano que señala si la solicitud de servicio se ha escalado.
Descripción Este indicador se establece en true si la solicitud de servicio ha sido objeto de un escalamiento funcional o jerárquico. Por lo general, se escala una solicitud cuando no avanza según lo previsto, está a punto de incumplir un SLA o requiere la aprobación o intervención de una autoridad superior. Este atributo es clave para el Dashboard de Análisis de eficiencia del escalamiento de solicitudes. Permite filtrar y analizar las rutas del proceso de las solicitudes escaladas para comprender qué las desencadena, cuánto tardan en resolverse después del escalamiento y qué eficacia tiene el proceso. Por qué es importante Permite aislar y analizar las solicitudes que requirieron un escalamiento, lo que ayuda a identificar puntos débiles del proceso estándar o factores que desencadenan problemas complejos. Dónde obtenerlo Por lo general, no corresponde a un único campo. Se obtiene al buscar actividades específicas relacionadas con el escalamiento en el registro de auditoría o cambios en la prioridad o la asignación que sigan un protocolo de escalamiento. Ejemplos truefalse
	Se incumplió el SLA IsSlaBreached	Indicador booleano que señala si la solicitud de servicio se resolvió después de la fecha objetivo del 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». Ofrece un resultado binario sencillo del rendimiento del SLA para cada solicitud. Este atributo es esencial para el Dashboard de Resumen de cumplimiento del SLA y el KPI de tasa de cumplimiento del SLA. Facilita la agregación de datos para calcular las tasas generales de cumplimiento y permite filtrar las solicitudes incumplidas y comparar sus características de proceso con las de las solicitudes que sí cumplieron el SLA. Así, ayuda a identificar las causas raíz de los incumplimientos. Por qué es importante Simplifica el análisis del rendimiento del SLA al convertir la comparación entre 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 gestión de solicitudes de servicio

Para descubrir y visualizar el proceso con precisión, registre en el registro de eventos estos pasos clave y sus hitos.

6 Recomendado 8 Opcional

	Actividad	Descripción
	Atención en curso	El agente o equipo asignado ha comenzado a trabajar activamente en 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 atención que aporta valor. Analizar el tiempo dedicado a esta fase ayuda a comprender la productividad de los recursos y la complejidad de la atención. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «En curso». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «En curso». Tipo de evento inferred
	Solicitud asignada	La solicitud de servicio se ha asignado a un agente o equipo responsable de completar el trabajo. Esto marca el final de la fase de clasificación inicial.
Por qué es importante Este hito es fundamental para medir el tiempo de clasificación y analizar la carga de trabajo de los agentes. Las reasignaciones frecuentes pueden indicar problemas de enrutamiento o falta de habilidades. Dónde obtenerlo Este evento puede capturarse directamente en el registro de auditoría de los campos «Assigned Group» o «Assignee» del formulario SRM:Request o de formularios relacionados con la atención, como WOI:WorkOrder. Capturar Marca de tiempo del registro de auditoría que muestra cuándo se asignó por primera vez un valor no nulo al campo «Assignee». Tipo de evento explicit
	Solicitud de servicio cancelada	Quien presentó la solicitud o la mesa de ayuda la ha retirado antes de que finalizara la atención. Este es un estado final de la solicitud.
Por qué es importante El seguimiento de las cancelaciones ayuda a identificar patrones, como solicitudes incorrectas o servicios que ya no se necesitan, y permite mejorar el catálogo de servicios. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Cancelada». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «Cancelada». 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 el período de confirmación.
Por qué es importante Esta actividad representa el final definitivo del proceso. El tiempo entre «Resuelta» y «Cerrada» puede revelar ineficiencias en el procedimiento de cierre. Dónde obtenerlo Se infiere a partir del cambio de estado final del formulario SRM:Request a «Cerrada». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «Cerrada». 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 entrada en el formulario SRM:Request con un estado inicial, normalmente «Enviada».
Por qué es importante Este es el punto de partida de cada caso de solicitud de servicio. Es esencial para medir la duración total del 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, «Enviada») de un registro en el formulario SRM:Request. Capturar Identifique la marca de tiempo de creación de un nuevo ID de solicitud de servicio en el formulario SRM:Request cuando el estado sea «Enviada». Tipo de evento inferred
	Solicitud de servicio resuelta	La atención de la solicitud de servicio ha finalizado y se ha comunicado la resolución a quien la presentó. La solicitud espera la confirmación final o se cerrará automáticamente tras un período establecido.
Por qué es importante Hito clave que marca el final del ciclo de prestación del servicio. Es el principal punto de referencia para medir el tiempo de resolución y el cumplimiento de los SLA. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Resuelta» o «Completada». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «Resuelta» o «Completada». Tipo de evento inferred
	Información solicitada al usuario	El agente responsable de atender la solicitud necesita información adicional de quien la presentó para poder continuar. Normalmente, la solicitud pasa al estado «Pendiente».
Por qué es importante Esta actividad es clave para calcular el «Tiempo de espera por información externa» e identificar con qué frecuencia se detienen las solicitudes por falta de información. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a «Pendiente», junto con un motivo como «En espera del cliente» o «A la espera de información». Capturar Marca de tiempo del cambio de estado a «Pendiente», junto con un motivo de estado específico. Tipo de evento inferred
	Resolución confirmada por el usuario	Quien presentó la solicitud ha confirmado que el servicio se prestó satisfactoriamente y que la solicitud está resuelta. Esto suele activar el cierre definitivo de la solicitud.
Por qué es importante Ofrece un indicador claro de la satisfacción del cliente y concluye formalmente la interacción de servicio. Permite distinguir la resolución del proceso de la aceptación del cliente. Dónde obtenerlo Este evento puede registrarse en los registros de trabajo o las notas de actividad de SRM:Request cuando el usuario confirma la resolución a través del portal o por correo electrónico. No siempre corresponde a un estado independiente. Capturar Revise los registros de trabajo (SRM:WorkInfo) para encontrar entradas que indiquen la confirmación del usuario o la finalización de una encuesta. Tipo de evento explicit
	Solicitud aprobada	La parte responsable ha aprobado formalmente la solicitud de servicio, por lo que puede continuar el proceso de atención. Este evento suele producirse después del estado «En espera de aprobación».
Por qué es importante Marca el final del subproceso de aprobación y es un hito clave para medir cuánto tardan las aprobaciones y cómo afectan al tiempo total de resolución. Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request de «En espera de aprobación» a un estado posterior, como «Planificación» o «En curso». La decisión de aprobación se registra en los formularios de aprobación relacionados. Capturar Marca de tiempo del cambio de estado que se produce después de «En espera de aprobación» tras una decisión favorable. Tipo de evento inferred
	Solicitud en revisión	El equipo de la mesa de ayuda realiza una revisión inicial y clasifica la solicitud de servicio para determinar su naturaleza, prioridad y equipo responsable de atenderla. Esto suele reflejarse en un cambio de estado del registro de la solicitud.
Por qué es importante El seguimiento de esta actividad permite medir la eficiencia de la clasificación inicial e identificar demoras entre el envío y la asignación, un dato clave para el KPI «Tiempo medio de clasificación». Dónde obtenerlo Se infiere a partir de un cambio de estado en el formulario SRM:Request a un valor como «En revisión» o «Planificación». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «En revisión». Tipo de evento inferred
	Solicitud pendiente de aprobación	La solicitud de servicio se ha enviado a una persona aprobadora designada o a un grupo de aprobación y espera una decisión antes de que pueda comenzar su atención. Este paso es habitual en solicitudes relacionadas con costes o derechos de acceso.
Por qué es importante Esta actividad permite aislar las demoras relacionadas con las aprobaciones, analizar sus tiempos de ciclo 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 «En espera de aprobación». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «En espera de aprobación». Tipo de evento inferred
	Solicitud reanudada	La solicitud de servicio ha salido del estado pendiente o de espera, normalmente después de que el usuario haya proporcionado la información necesaria. El agente responsable reanuda el trabajo.
Por qué es importante Marca el final de un período de espera y permite medir con precisión los tiempos de espera por información externa y su impacto en el cumplimiento de los SLA. Dónde obtenerlo Se infiere cuando el estado de SRM:Request cambia de «Pendiente» a «En curso». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia de «Pendiente» a «En curso». Tipo de evento inferred
	Solicitud rechazada	La solicitud de servicio se rechazó durante la fase de aprobación. Este estado final detiene el proceso antes de que comience la atención.
Por qué es importante El análisis de las solicitudes rechazadas puede revelar problemas en las justificaciones, 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 «Rechazada». Capturar Marca de tiempo del evento de actualización en que el campo «Status» de SRM:Request cambia a «Rechazada». Tipo de evento inferred
	Solución implementada	El agente ha completado el trabajo técnico necesario para atender la solicitud de servicio. La solicitud está lista para que el usuario confirme la solución antes de que se marque formalmente como resuelta.
Por qué es importante Esta actividad distingue la finalización del trabajo técnico de la resolución formal y ayuda a identificar demoras entre el fin del trabajo y la confirmación del usuario. Dónde obtenerlo Puede inferirse a partir de un cambio de estado en un ticket de atención del sistema, por ejemplo, cuando una orden de trabajo pasa a «Completada» antes de que la solicitud principal SRM:Request se marque como «Resuelta». Capturar Marca de tiempo en que un ticket del sistema, como una orden de trabajo o un incidente, 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 y abra Smart Reporting. Según la versión, puede aparecer como 'Informes' o 'Smart Reporting'.
Cree un informe: En la interfaz de Smart Reporting, seleccione la opción para crear un informe nuevo. Elija 'Informe' como tipo.
Seleccione la fuente de datos y la vista: Se le pedirá que seleccione una fuente de datos. Elija la fuente de datos principal de AR System. En el campo de vista, busque y seleccione la vista de solicitudes de servicio, 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 'Datos' y añada estas uniones:
- SRM:WorkInfo (con SR ID+ = Request Number) para obtener detalles de las actividades de atención y los registros de trabajo.
- AP:Signature (con Request = SRInstanceID) para obtener eventos relacionados con las aprobaciones, como aprobaciones y rechazos. Es posible que deba crear una unión personalizada.
Defina las columnas del informe: Arrastre los campos necesarios de los formularios unidos al área 'Columnas'. 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 método se basa en crear una serie de campos calculados que representen la marca de tiempo de cada actividad. Vaya a la pestaña 'Datos' y cree un campo calculado 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 inicio del trabajo: Use MIN(Submit Date) de SRM:WorkInfo, agrupado por número de solicitud.
Prepare el informe para combinar los datos: Smart Reporting no tiene un botón sencillo de 'UNION ALL' como SQL. Para lograrlo, cree un solo informe y use funciones avanzadas o subconsultas para transformar 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 convertir estas columnas en filas independientes, una por 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 específico. Si trabaja en un entorno multiinquilino, añada también filtros por 'Empresa'.
Ejecute el informe y revise los datos: Ejecute el informe para comprobar que los datos se obtienen correctamente. Verifique las uniones, que las columnas tengan datos 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 permiten preparar fácilmente los datos para importarlos en herramientas de Process Mining.
Transforme los datos: Después de exportarlos, convierta el formato ancho (una fila por solicitud de servicio con muchas columnas de marcas de tiempo) en un formato largo (una fila por actividad). Use un script, por ejemplo, en Python o PowerShell, o una herramienta como Power Query de Excel para convertir las columnas de marcas de tiempo en dos columnas: ActivityName y EventStartTime. Este paso es esencial para crear la estructura necesaria del registro de eventos.

Configuración

Requisitos previos: Necesita una cuenta de usuario con permisos para generar informes en BMC Helix ITSM, incluido el acceso para crear y ejecutar informes en Smart Reporting. También necesita permisos de lectura para los formularios SRM:Request, SRM:WorkInfo y AP:Signature.
Formularios principales: El informe se crea uniendo estos formularios:
- SRM:Request: formulario principal con los detalles de la solicitud de servicio.
- SRM:WorkInfo: contiene registros de trabajo que permiten identificar las actividades de atención.
- AP:Signature: contiene registros de aprobación, necesarios para hacer un seguimiento de las actividades relacionadas con las aprobaciones.
Filtro por intervalo de fechas: Aplique siempre un filtro de intervalo de fechas al campo SRM:Request.Submit Date. Se recomienda usar entre 3 y 6 meses de datos para obtener una muestra representativa sin afectar demasiado el rendimiento del informe.
Filtros importantes: Además del intervalo de fechas, filtre por Company para aislar los datos de una entidad empresarial específica. También puede excluir tipos de solicitud o estados que no sean pertinentes para el análisis del proceso, como 'Borrador'.
Consideraciones de rendimiento: Los informes que unen varios formularios para un intervalo de fechas amplio pueden tardar en generarse. Si el volumen de datos es grande, se recomienda programar su ejecución fuera de las horas de mayor actividad. Si se producen tiempos de espera agotados, divida la extracción en períodos mensuales más cortos.

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: Use el cliente de base de datos para conectarse al servidor de la base de datos de AR System.
Prepare la consulta: Copie la consulta SQL completa de la sección 'Consulta' de este documento en el editor de consultas de su cliente de base de datos.
Defina los parámetros: Localice los valores de marcador de posición en la consulta. Sustituya :start_date y :end_date por el intervalo de fechas que desea extraer, por ejemplo, '2023-01-01' y '2023-12-31'. Si corresponde, sustituya :company_name por el nombre de la empresa que desea usar como filtro.
Ejecute la consulta: Ejecute la consulta SQL modificada. Según el intervalo de fechas y el tamaño del sistema, puede tardar varios minutos.
Revise los resultados: Al finalizar la consulta, se mostrará un conjunto de resultados con el registro de eventos. Revise brevemente los datos para comprobar que se hayan cargado correctamente y que incluyan las columnas y actividades esperadas.
Verifique las marcas de tiempo: Compruebe que todas las columnas de marcas de tiempo, en particular EventStartTime, EventEndTime y LastDataUpdate, tengan un formato coherente, como 'YYYY-MM-DD HH:MI:SS'. Si la base de datos devuelve otro formato, ajuste las funciones TO_CHAR o CONVERT de la consulta según corresponda.
Exporte los datos: Use la función de exportación del cliente de base de datos para guardar todo el conjunto de resultados en un archivo CSV. Elija la codificación UTF-8 para garantizar la compatibilidad.
Prepare el archivo para cargarlo: Asigne un nombre adecuado al archivo, por ejemplo, servicerequest_eventlog.csv. Ya estará listo para cargarlo en la plataforma ProcessMind.

Configuración

Credenciales de la base de datos: Se requiere una cuenta de usuario de solo lectura para la base de datos de AR System. Así se evitan modificaciones accidentales de los datos y se siguen las prácticas recomendadas de seguridad.
Filtro por intervalo de fechas: La consulta incluye los marcadores de posición :start_date y :end_date. Es fundamental definir 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 al campo Submit_Date de la solicitud de servicio.
Filtro por empresa: Se incluye el marcador de posición :company_name para filtrar las solicitudes de una empresa operativa específica. Si necesita extraer datos de todas las empresas, puede eliminar la línea AND req.Company = :company_name o asignarle un comodín, si el sistema lo admite.
Valores de estado: La consulta usa los valores enteros estándar de estado de BMC Helix ITSM (por ejemplo, Submitted = 0, In Review = 1, etc.). Su sistema puede tener estados personalizados o asignaciones de números enteros diferentes. Compruebe estos valores en el formulario SYS:Status o en Developer Studio de su sistema y, si es necesario, ajuste las cláusulas WHERE de la consulta.
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 de mayor actividad para reducir al mínimo el impacto en el rendimiento del sistema.

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 instalada en su sistema la versión 3.6 o posterior de Python. Instale la biblioteca requests, necesaria para realizar llamadas a la API HTTP, ejecutando pip install requests en la terminal o el símbolo del sistema.
Obtenga las credenciales de la API: Cree u obtenga las credenciales de una cuenta de servicio dedicada en BMC Helix ITSM. Esta cuenta necesita, como mínimo, 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 el nombre de usuario, la 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 que usa el flujo de trabajo de solicitudes de servicio de su organización.
Defina el período de extracción: Modifique las variables START_DATE y END_DATE del script. Estas definen el período que se extraerá según la fecha de envío de la solicitud de servicio. Para las pruebas iniciales, use un intervalo corto, como un solo día.
Ejecute el script: Ejecútelo desde la terminal con el comando python extract_servicerequests.py. Primero, el script se autenticará en la API para obtener un token.
Obtenga los datos iniciales: El script consulta el formulario SRM:Request para recuperar la lista de todas las solicitudes de servicio creadas dentro del intervalo de fechas especificado. En este paso, obtiene 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 recuperar 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 por 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 'Solicitud de servicio enviada' para cada solicitud, usando Submit Date del formulario principal SRM:Request.
Exporte a CSV: Una vez procesadas todas las solicitudes de servicio y sus historiales, el script reúne las filas generadas en una sola lista y guarda los datos en un archivo CSV llamado servicerequest_event_log.csv. El archivo queda listo para cargarse en una herramienta de Process Mining.

Configuración

Puntos de conexión de la API: El script usa principalmente dos puntos de conexión de la API. La autenticación se realiza mediante api/jwt/login. Los datos se consultan en arsys/v1/entry/SRM:Request para obtener la lista de casos y en arsys/v1/entry/[AUDIT_FORM_NAME] para consultar el historial de eventos.
Permisos de la cuenta de servicio: Se requiere una cuenta de servicio dedicada con acceso de lectura al formulario SRM:Request y al formulario de registro de auditoría del sistema. El uso de una cuenta de servicio es fundamental para la seguridad y la trazabilidad.
Filtro por intervalo de fechas: El script filtra las solicitudes de servicio según 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 la base 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án los estados del flujo de trabajo que no estén incluidos en el diccionario.
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. Identifique el nombre correcto del formulario de su entorno que almacena el historial de cambios de estado de las solicitudes de servicio y actualice la variable AUDIT_FORM_NAME según corresponda.
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 1000 registros por solicitud y equilibrar el rendimiento con el uso de memoria.

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

¿Todo listo para comenzar?

Use esta plantilla para agilizar la recopilación de datos y comenzar con confianza su recorrido en Process Mining. Empiece hoy a optimizar la gestión de solicitudes de servicio.

Volver a la guía de mejora

Descargar Template

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

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

Comience su prueba gratuita

No se requiere tarjeta de crédito. Comience en unos minutos.

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

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

Atributos de gestión de solicitudes de servicio

Actividades de gestión de solicitudes de servicio

Guías de extracción

Smart Reporting de BMC Helix ITSM para solicitudes de servicio

Pasos

Configuración

Consulta de ejemplo sql

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

Pasos

Configuración

Consulta de ejemplo sql

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

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

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