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

Template universal de Process Mining
Su Template de datos para la gestión de solicitudes de servicio

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

Template universal de Process Mining

Este es nuestro Template genérico de datos para Process Mining de Gestión de solicitudes de servicio. Para obtener indicaciones más específicas, use nuestros Templates para cada sistema.

Seleccione un sistema específico
  • Campos de datos estandarizados para realizar análisis coherentes en distintos sistemas.
  • Actividades clave del proceso identificadas para descubrirlo de forma integral.
  • Una base versátil para optimizar cualquier flujo de trabajo de solicitudes de servicio.
¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Atributos de la gestión de solicitudes de servicio

Estos son los campos de datos recomendados para incluir en el registro de eventos. Proporcionan el contexto necesario para analizar en profundidad el proceso de gestión de solicitudes de servicio.
5 Obligatorio 6 Recomendado 6 Opcional
Nombre Descripción
Actividad
Activity
Nombre de una tarea, un evento o un cambio de estado específico que se produjo durante el ciclo de vida de la solicitud de servicio.
Descripción

El atributo Actividad describe un paso o una acción específicos realizados en una solicitud de servicio. Estas actividades son los componentes secuenciales del proceso, como 'Solicitud creada', 'Solicitud asignada', 'Trabajo en curso' y 'Solicitud cerrada'. Cada actividad representa un momento concreto del recorrido de una solicitud de servicio.

El análisis de las actividades es fundamental en Process Mining, ya que permite descubrir y visualizar el flujo real del proceso. Al examinar la secuencia y la frecuencia de las actividades, los analistas pueden identificar las rutas habituales, las desviaciones del proceso estándar, los cuellos de botella que dejan solicitudes estancadas y los ciclos de retrabajo en los que se repiten pasos innecesariamente.

Por qué es importante

Define los pasos del proceso y permite descubrir el flujo real, los cuellos de botella y las desviaciones.

Dónde obtenerlo

A menudo se obtiene de los registros de cambios de estado, las tablas de eventos o los registros de auditoría asociados al objeto de solicitud de servicio.

Ejemplos
Solicitud de servicio creadaSolicitud asignadaSolicitud resueltaSolicitud de servicio cerrada
Hora de inicio
StartTime
Marca de tiempo que indica cuándo comenzó una actividad o un evento.
Descripción

La Hora de inicio registra la fecha y hora exactas en que comenzó una actividad específica. Esta marca de tiempo es esencial para ordenar cronológicamente los eventos y calcular la duración de las actividades y del ciclo de vida completo del caso. Cada actividad del proceso debe tener una Hora de inicio correspondiente para crear un registro de eventos preciso.

En el análisis de procesos, la Hora de inicio se utiliza para calcular KPI clave, como el tiempo de ciclo, el tiempo de espera entre actividades y el tiempo de procesamiento de las actividades. Permite crear una vista temporal del proceso, destacar las demoras y detectar qué pasos consumen más tiempo. Las marcas de tiempo precisas son fundamentales para cualquier análisis del rendimiento.

Por qué es importante

Esta marca de tiempo es esencial para ordenar correctamente los eventos y calcular todas las métricas relacionadas con el tiempo, como los tiempos de ciclo y los cuellos de botella.

Dónde obtenerlo

Se encuentra en las tablas del registro de eventos o del registro de auditoría. A menudo se registra como 'fecha de creación' o 'marca de tiempo del evento' para cada actividad.

Ejemplos
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
ID de solicitud de servicio
CaseId
Identificador único de cada caso de solicitud de servicio. Se utiliza para hacer seguimiento de una solicitud desde su creación hasta su cierre.
Descripción

El ID de solicitud de servicio es la clave principal que identifica de forma única cada solicitud durante todo su ciclo de vida. Funciona como identificador del caso y vincula en una instancia de proceso coherente todas las actividades, los cambios de estado y los atributos relacionados.

En el análisis de Process Mining, este ID es fundamental para reconstruir el recorrido completo de cada solicitud. Al agrupar todos los eventos bajo un mismo CaseId, los analistas pueden visualizar los flujos del proceso, calcular la duración de los casos e identificar diferencias en la gestión de las solicitudes. Es la base de cualquier análisis del proceso de gestión de solicitudes de servicio.

Por qué es importante

Este ID es esencial para reunir todos los eventos de una solicitud de servicio y obtener una visión completa del proceso de principio a fin.

Dónde obtenerlo

Suele encontrarse en el encabezado o en la tabla principal de transacciones de solicitudes de servicio.

Ejemplos
SR-2023-00123REQ0045891TICKET-98765
Sistema de origen
SourceSystem
Identifica el sistema o la aplicación de donde proceden los datos de la solicitud de servicio.
Descripción

El atributo Sistema de origen especifica el nombre de la plataforma de gestión de servicios de TI (ITSM) u otra aplicación de la que se extrajeron los datos. En entornos con varios sistemas, este campo ayuda a distinguir las fuentes de datos y a mantener clara su trazabilidad.

Aunque no se utiliza directamente en la mayoría de los análisis del flujo del proceso, es fundamental para la gobernanza de datos, la validación y la resolución de problemas. Al combinar datos de varias fuentes, este atributo permite a los analistas segmentar la vista del proceso por sistema y detectar diferencias en la ejecución del proceso o en la calidad de los datos entre plataformas.

Por qué es importante

Es fundamental para la gobernanza de datos y la resolución de problemas, ya que aclara el origen de los datos, especialmente en entornos con varios sistemas integrados.

Dónde obtenerlo

Este valor suele añadirse durante el proceso de extracción de datos (ETL) y no es un campo propio del sistema de origen.

Ejemplos
ServiceNowJira Service ManagementZendesk
Última actualización de los datos
LastDataUpdate
Marca de tiempo que indica cuándo se actualizaron por última vez los datos desde el sistema de origen.
Descripción

Última actualización de los datos indica la fecha y hora de la extracción o actualización más reciente. Informa sobre la antigüedad de los datos que se están analizando y permite saber si el análisis refleja el estado actual o una situación anterior.

Este atributo es esencial para el seguimiento operativo y la elaboración de informes, ya que aporta contexto sobre la actualidad de la información obtenida. Ayuda a confiar en los datos y a tomar decisiones fundamentadas según su vigencia. Por ejemplo, un Dashboard con datos actualizados hace una semana se interpretaría de forma distinta a uno actualizado hace una hora.

Por qué es importante

Indica la vigencia de los datos, algo esencial para garantizar que los análisis sean pertinentes y se basen en información actualizada.

Dónde obtenerlo

Este campo de metadatos suele generarse y almacenarse durante el proceso de extracción de datos (ETL).

Ejemplos
2023-10-27T08:00:00Z2023-10-26T23:59:59Z
Agente asignado
AssignedAgent
Usuario o agente asignado actualmente a la gestión de la solicitud de servicio.
Descripción

Agente asignado es la persona responsable de gestionar la solicitud de servicio en un momento determinado. La solicitud puede asignarse a distintos agentes a lo largo de su ciclo de vida.

Este atributo es clave para analizar el rendimiento y la carga de trabajo. Permite a las organizaciones medir y comparar el rendimiento de cada agente, incluidos sus tiempos medios de resolución y el volumen de solicitudes que gestiona. También sirve para analizar las reasignaciones entre agentes, que pueden indicar problemas en la clasificación inicial, la especialización de los agentes o el equilibrio de la carga de trabajo.

Por qué es importante

Permite analizar el rendimiento de cada agente, la distribución de la carga de trabajo y la frecuencia de las reasignaciones entre agentes.

Dónde obtenerlo

Disponible en el registro de solicitudes de servicio. Los cambios en este campo suelen quedar registrados en un registro de auditoría o una tabla de historial.

Ejemplos
John SmithJane Doeagent_user_123
Equipo asignado
AssignedTeam
Grupo o equipo de soporte asignado actualmente a la solicitud de servicio.
Descripción

Equipo asignado se refiere al grupo de soporte responsable de la solicitud de servicio. Según los conocimientos necesarios, las solicitudes suelen derivarse entre distintos equipos, como una mesa de ayuda de nivel 1, un equipo de redes o un equipo de desarrollo de software.

El análisis de las transferencias entre equipos es una parte fundamental de Process Mining aplicado a la gestión de servicios. Este atributo permite visualizar las transferencias entre equipos y detectar problemas de comunicación o demoras. También permite comparar el rendimiento de los equipos en cuanto a eficiencia, volumen de solicitudes y capacidad para resolverlas sin más escalaciones.

Por qué es importante

Es fundamental para analizar las transferencias entre equipos, detectar demoras y comparar el rendimiento de los equipos.

Dónde obtenerlo

Campo estándar del registro de solicitudes de servicio. Los cambios en este campo quedan registrados en un registro de auditoría.

Ejemplos
Mesa de ayuda de nivel 1Operaciones de redSoporte de sistemas de RR. HH.
Estado de la solicitud
RequestStatus
Estado actual o histórico de la solicitud de servicio en el momento de un evento, como 'En curso' o 'Cerrado'.
Descripción

El Estado de la solicitud indica en qué situación se encontraba la solicitud de servicio en un momento determinado de su ciclo de vida. Entre los estados habituales se incluyen Nuevo, En curso, Pendiente, Resuelto y Cerrado. Este atributo muestra en qué punto del proceso general se encuentra la solicitud.

Analizar el Estado de la solicitud es clave para comprender el flujo del proceso y las transiciones entre estados. Permite filtrar casos, detectar solicitudes estancadas en un estado concreto y medir cuánto tiempo permanecen en cada estado. Por ejemplo, analizar cuánto tiempo permanecen las solicitudes en estado 'Pendiente' puede revelar demoras causadas por la espera de información de los usuarios o de equipos externos.

Por qué es importante

Permite analizar cuánto tiempo permanecen las solicitudes en cada estado y detectar cuellos de botella o demoras en el proceso.

Dónde obtenerlo

Disponible en la tabla principal de solicitudes de servicio o en los registros del historial de estados.

Ejemplos
En cursoPendiente del clienteResueltoCerrado
Fecha límite del SLA
SlaDueDate
Fecha y hora límite para resolver la solicitud según el acuerdo de nivel de servicio (SLA).
Descripción

La Fecha límite del SLA es una marca de tiempo objetivo que se calcula según el acuerdo de nivel de servicio asociado a la solicitud. Se determina en función de factores como la prioridad y el tipo de solicitud, así como la hora de creación, y establece el plazo previsto para resolverla.

Este atributo es la base de todos los análisis de cumplimiento del SLA. Al comparar el tiempo real de resolución con la Fecha límite del SLA, las organizaciones pueden determinar si la solicitud se resolvió a tiempo o si se incumplió el SLA. Es un KPI fundamental para medir la calidad del servicio y detectar problemas sistémicos que causan demoras e incumplimientos.

Por qué es importante

Es el valor de referencia para medir el rendimiento. Se utiliza para calcular las tasas de cumplimiento del SLA y detectar las solicitudes que incumplen el acuerdo.

Dónde obtenerlo

A menudo es un campo calculado del registro de solicitudes de servicio, determinado por la política de SLA aplicada.

Ejemplos
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
Prioridad de la solicitud
RequestPriority
Nivel de prioridad asignado a la solicitud, que indica su impacto en el negocio y su urgencia.
Descripción

La Prioridad de la solicitud es una clasificación que ayuda a los equipos de soporte a determinar el orden en que deben atender las solicitudes. Suele basarse en una combinación del impacto de la solicitud en el negocio y su urgencia. Los niveles de prioridad habituales son Baja, Media, Alta y Crítica.

Este atributo es fundamental para analizar el rendimiento y asignar recursos. Los analistas pueden comparar los tiempos de ciclo y el cumplimiento del SLA según los distintos niveles de prioridad para comprobar que las solicitudes de alta prioridad se atiendan adecuadamente. También ayuda a detectar si se descuidan las solicitudes de baja prioridad o si los equipos de soporte aplican correctamente el sistema de priorización.

Por qué es importante

Es esencial para analizar si las solicitudes se atienden según su importancia para el negocio y comprender cómo influye la prioridad en el tiempo de resolución.

Dónde obtenerlo

Suele ser un campo estándar del registro principal de solicitudes de servicio.

Ejemplos
BajaMediaAltaCrítico
Tipo de servicio
ServiceType
Categoría o tipo de servicio que solicita el usuario.
Descripción

Tipo de servicio clasifica la naturaleza de la solicitud. Puede abarcar desde solicitudes de hardware nuevo o acceso a software hasta consultas generales o soporte técnico. Esta clasificación ayuda a derivar la solicitud al equipo adecuado y a comprender la demanda de los distintos servicios.

En el análisis de procesos, Tipo de servicio es una dimensión útil para segmentar los datos. Al filtrar el mapa del proceso por tipo de servicio, las organizaciones pueden descubrir que algunas solicitudes siguen procesos muy distintos, tienen tiempos de ciclo más largos o requieren más retrabajo. Esta información permite orientar las iniciativas de mejora a categorías de servicio específicas.

Por qué es importante

Permite filtrar y comparar los procesos de distintas categorías de solicitudes para detectar cuellos de botella o ineficiencias propias de cada tipo.

Dónde obtenerlo

Campo estándar del registro de solicitudes de servicio, a menudo vinculado a un catálogo de servicios.

Ejemplos
Solicitud de hardwareAcceso a softwareRestablecimiento de contraseñaConsulta general
¿Se incumplió el SLA?
IsSlaBreached
Indicador que señala si la solicitud de servicio se resolvió después de la fecha límite del SLA.
Descripción

Este atributo booleano indica si la solicitud de servicio incumplió el acuerdo de nivel de servicio definido. Su valor es verdadero si la solicitud se resolvió después de 'SlaDueDate' y falso en caso contrario.

Este atributo simplifica la elaboración de informes y el análisis del cumplimiento del SLA. En lugar de comparar fechas en cada consulta, este indicador permite filtrar y agregar datos fácilmente. Es una métrica principal de los Dashboards centrados en el rendimiento del SLA y ayuda a identificar rápidamente el volumen y el porcentaje de solicitudes que no cumplen los objetivos de servicio.

Por qué es importante

Ofrece un indicador claro y sencillo para analizar el rendimiento del SLA y facilita el filtrado y la elaboración de informes sobre las solicitudes que incumplen el acuerdo.

Dónde obtenerlo

Este atributo se calcula durante la transformación de datos, comparando la marca de tiempo de resolución final con el campo 'SlaDueDate'.

Ejemplos
truefalse
Canal de envío
SubmissionChannel
Método o canal por el que se envió la solicitud de servicio.
Descripción

Canal de envío indica cómo se creó la solicitud de servicio, por ejemplo, a través de un portal de autoservicio, por correo electrónico, por teléfono o mediante una API. Cada canal puede estar asociado a procesos o expectativas de los usuarios distintos.

Analizar el proceso según el canal de envío puede revelar información importante. Por ejemplo, las solicitudes enviadas a través de un portal de autoservicio pueden estar más estructuradas y resolverse más rápido que las enviadas por correo electrónico, que quizá requieran introducir los datos manualmente. Este análisis puede ayudar a las organizaciones a promover canales más eficientes o mejorar los procesos de los menos eficientes.

Por qué es importante

Ayuda a determinar si el método de envío influye en la eficiencia del proceso, el tiempo de resolución o la tasa de resolución en el primer contacto.

Dónde obtenerlo

Suele ser un campo estándar del registro de solicitudes de servicio.

Ejemplos
PortalCorreo electrónicoTeléfonoChat
Código de resolución
ResolutionCode
Código o categoría que indica el resultado final o el motivo del cierre de la solicitud.
Descripción

El Código de resolución ofrece una forma estructurada de clasificar el resultado de una solicitud de servicio. Algunos ejemplos son 'Resuelto por el usuario', 'Hardware reemplazado', 'Software implementado' o 'Solicitud duplicada'. Por lo general, el agente introduce esta información al cerrar la solicitud.

Estos códigos son útiles para analizar las causas raíz. Al examinar la frecuencia de los distintos códigos de resolución, las organizaciones pueden detectar problemas recurrentes, soluciones habituales y oportunidades para crear artículos de la base de conocimientos o resolver solicitudes automáticamente. Por ejemplo, un número elevado de resoluciones por 'Restablecimiento de contraseña' podría justificar la inversión en una herramienta de autoservicio para restablecer contraseñas.

Por qué es importante

Permite analizar las causas raíz al clasificar cómo se resuelven las solicitudes, lo que ayuda a detectar tendencias y oportunidades para gestionar problemas de forma proactiva.

Dónde obtenerlo

Campo que el agente suele completar manualmente al resolver o cerrar la solicitud de servicio.

Ejemplos
AtendidaError del usuarioCancelada por el usuarioYa no se necesita
Departamento del solicitante
RequestorDepartment
Departamento o unidad de negocio del usuario que envió la solicitud.
Descripción

Este atributo identifica el departamento o la unidad de negocio de la persona que inició la solicitud de servicio. Aporta contexto organizativo a la solicitud.

Analizar las solicitudes por departamento puede ayudar a detectar necesidades, tendencias o problemas específicos de cada área. Por ejemplo, un volumen elevado de cierto tipo de solicitudes del departamento de Finanzas podría indicar la necesidad de ofrecer formación específica o mejorar un sistema. También permite elaborar informes de asignación de costes y comprender la demanda de servicios de TI en toda la organización.

Por qué es importante

Aporta contexto organizativo y permite analizar los patrones de solicitudes y la demanda de servicios por unidad de negocio.

Dónde obtenerlo

Esta información suele obtenerse del perfil de usuario del solicitante en el directorio de empleados o en el sistema ITSM.

Ejemplos
FinanzasRecursos HumanosMarketingOperaciones de TI
Hora de finalización
EndTime
Marca de tiempo que indica cuándo se completó una actividad o un evento.
Descripción

La Hora de finalización registra la fecha y hora exactas en que terminó una actividad específica. Mientras que la Hora de inicio marca el comienzo, la Hora de finalización señala el final y determina la duración de un paso del proceso. No todos los eventos tienen una Hora de finalización diferenciada, ya que algunos son instantáneos.

Este atributo es esencial para calcular el tiempo de procesamiento de cada actividad. Al restar la Hora de inicio de la Hora de finalización, los analistas pueden medir cuánto tiempo dedican los agentes o los sistemas a trabajar activamente en una tarea. Esto ayuda a detectar las actividades que consumen más tiempo y que podrían optimizarse o automatizarse.

Por qué es importante

Permite calcular los tiempos de procesamiento de las actividades y detectar qué pasos del proceso consumen más tiempo.

Dónde obtenerlo

Se encuentra en las tablas del registro de eventos o del registro de auditoría. Si no está disponible de forma explícita, puede calcularse a partir de la Hora de inicio de la siguiente actividad.

Ejemplos
2023-10-26T10:05:12Z2023-10-26T15:00:45Z2023-10-28T09:20:00Z
Número de reasignaciones
ReassignmentCount
Número total de veces que la solicitud se reasignó entre distintos agentes o equipos.
Descripción

Número de reasignaciones es una métrica que cuenta las veces que una solicitud de servicio se transfirió de un agente o equipo a otro. Un número elevado puede indicar problemas como una derivación inicial incorrecta, falta de conocimientos del agente o una asignación de responsabilidades poco clara.

Es un indicador clave de ineficiencia del proceso. En Process Mining, esta métrica permite cuantificar las idas y vueltas de una solicitud. Analizar los casos con muchas reasignaciones puede revelar oportunidades para mejorar la clasificación inicial, reforzar la formación de los agentes o definir mejor las responsabilidades de los equipos, de modo que las solicitudes se deriven correctamente desde el principio.

Por qué es importante

Es una métrica clave para detectar ineficiencias en el proceso. Un número elevado de reasignaciones suele estar relacionado con tiempos de resolución más largos y una menor satisfacción de los usuarios.

Dónde obtenerlo

Esta métrica se calcula contando cuántas veces cambian los campos 'AssignedAgent' o 'AssignedTeam' para un 'CaseId' determinado.

Ejemplos
0135
Obligatorio Recomendado Opcional

Actividades de gestión de solicitudes de servicio

Esta tabla describe los pasos clave del proceso y los hitos importantes que debe registrar para descubrir con precisión el proceso de solicitudes de servicio.
7 Recomendado 9 Opcional
Actividad Descripció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 la cola a un estado de trabajo activo.
Por qué es importante

Esta actividad marca el inicio del tiempo de atención activa. Analizar la duración de esta fase es clave para detectar ineficiencias en el proceso.

Dónde obtenerlo

Suele inferirse a partir del primer cambio de estado a «En curso» o «Activo» después de la asignación.

Capturar

Registre la marca de tiempo del primer cambio a un estado activo, como «En curso», después de asignar la solicitud.

Tipo de evento inferred
Información solicitada
El agente responsable de atender la solicitud necesita información adicional para continuar. Normalmente, la solicitud pasa a un estado pendiente o en espera, lo que detiene el cómputo del tiempo de atención.
Por qué es importante

Esta actividad pone de manifiesto la dependencia del solicitante y es una de las principales causas de que se alarguen los tiempos de ciclo. El seguimiento de su frecuencia y duración permite detectar brechas de comunicación.

Dónde obtenerlo

Se infiere a partir de un cambio de estado a «Pendiente del cliente», «En espera de información del usuario» o «En espera».

Capturar

Utilice la marca de tiempo del cambio de estado de la solicitud a un estado que indique que está a la espera del usuario.

Tipo de evento inferred
Solicitud asignada
La solicitud de servicio se ha asignado a un agente o equipo responsable de atenderla. Esto marca el paso de la clasificación inicial a la cola de trabajo.
Por qué es importante

Este es un hito clave para medir los KPI del tiempo hasta la asignación y comprender cómo se distribuye la carga de trabajo entre equipos y personas.

Dónde obtenerlo

Se registra mediante el seguimiento de los cambios en los campos «Responsable» o «Grupo asignado» del historial o del registro de auditoría de la solicitud.

Capturar

Identifique la primera marca de tiempo en la que se completa el campo de responsable o de grupo de asignación.

Tipo de evento explicit
Solicitud de servicio cerrada
La solicitud de servicio se cierra formalmente y pasa a un estado archivado en el que ya no se pueden realizar más acciones. Esta es la última actividad de su ciclo de vida.
Por qué es importante

Esta actividad marca el final definitivo del proceso. El tiempo transcurrido entre la resolución y el cierre puede revelar demoras al confirmar las soluciones.

Dónde obtenerlo

Suele ser un cambio de estado final a 'Cerrado', que a menudo se produce automáticamente después de un periodo determinado en el estado 'Resuelto'.

Capturar

Use la marca de tiempo del registro de eventos correspondiente al cambio de estado a 'Cerrado'.

Tipo de evento explicit
Solicitud de servicio creada
Esta es la primera actividad del proceso y marca el envío y el registro formal de una nueva solicitud de servicio. Se registra cuando un usuario envía una solicitud a través de un portal, por correo electrónico u otro canal, y se genera un identificador único del caso.
Por qué es importante

Esta actividad marca el inicio del ciclo de vida del proceso, un dato fundamental para calcular el tiempo de ciclo total y analizar el volumen de solicitudes.

Dónde obtenerlo

Suele tratarse de un evento de creación explícito en la tabla principal de transacciones o tickets, con una marca de tiempo que corresponde a la creación del registro.

Capturar

Utilice la marca de tiempo de creación del registro principal de la solicitud de servicio.

Tipo de evento explicit
Solicitud reabierta
Una solicitud de servicio que ya se había resuelto ha vuelto a un estado activo. Esto suele ocurrir cuando el solicitante indica que la solución no funcionó o que el problema ha reaparecido.
Por qué es importante

Las solicitudes reabiertas indican directamente que hubo retrabajo y que la tasa de resolución en el primer intento es baja. Analizar estos eventos es fundamental para mejorar la calidad del servicio.

Dónde obtenerlo

Se infiere a partir de un cambio de estado de «Resuelta» o «Cerrada» a un estado abierto o en curso.

Capturar

Registre la marca de tiempo del cambio de estado de resuelto a activo.

Tipo de evento inferred
Solicitud resuelta
El agente ha terminado el trabajo para atender la solicitud y considera que esta se ha satisfecho. La solicitud pasa al estado «Resuelta», lo que suele detener el cómputo del SLA.
Por qué es importante

Este es el hito más importante del proceso de atención. El tiempo desde la creación hasta la resolución es un KPI principal para medir el rendimiento.

Dónde obtenerlo

Casi siempre se registra en el historial de la solicitud como un cambio de estado específico a «Resuelta» o «Atendida».

Capturar

Utilice la marca de tiempo del registro de eventos correspondiente al primer cambio de estado a «Resuelta» o su equivalente.

Tipo de evento explicit
Aprobación solicitada
La solicitud de servicio se ha enviado a la persona o al grupo designado para aprobarla y está pendiente de una decisión. Este paso es habitual en solicitudes que implican costes, seguridad o recursos.
Por qué es importante

El seguimiento de esta actividad ayuda a detectar demoras en la fase de aprobación, que suele ser un cuello de botella importante antes de iniciar el trabajo de cumplimiento de la solicitud.

Dónde obtenerlo

A menudo, se infiere a partir de un cambio de estado a «Pendiente de aprobación» o «En espera de aprobación» en el historial de la solicitud.

Capturar

Registre la marca de tiempo del cambio de estado de la solicitud a un estado pendiente de aprobación.

Tipo de evento inferred
Dependencia externa activada
La solicitud de servicio se ha transferido a un proveedor externo o a otro departamento interno para que actúe. La solicitud queda a la espera de la respuesta de ese tercero.
Por qué es importante

Esto permite aislar y medir las demoras causadas por terceros, algo fundamental para analizar el rendimiento con precisión y gestionar los SLA.

Dónde obtenerlo

Suele inferirse a partir de un cambio de estado a «Pendiente del proveedor» o «En espera de un tercero», o de la asignación a un grupo específico de proveedores.

Capturar

Identifique la marca de tiempo del cambio de estado a uno que indique una dependencia de terceros.

Tipo de evento inferred
Información proporcionada
El solicitante ha proporcionado la información necesaria, lo que permite al agente reanudar el trabajo. Este evento suele sacar la solicitud de un estado pendiente.
Por qué es importante

Este evento marca el fin de un periodo de espera causado por el usuario. El tiempo entre «Información solicitada» y esta actividad es una métrica clave para analizar las dependencias.

Dónde obtenerlo

A menudo, se infiere cuando el estado de una solicitud pasa de pendiente a activo, normalmente a raíz de un comentario o una actualización del usuario.

Capturar

Registre la marca de tiempo del momento en que el estado vuelve a ser activo después de estar pendiente del usuario.

Tipo de evento inferred
Resolución confirmada
El solicitante ha confirmado expresamente que el servicio se prestó de forma satisfactoria y que la solicitud está resuelta. Esta confirmación indica que la resolución fue satisfactoria.
Por qué es importante

Esta actividad aporta datos valiosos para medir la satisfacción del cliente y permite validar la eficacia de la resolución antes del cierre definitivo.

Dónde obtenerlo

Puede tratarse de un cambio de estado explícito o inferirse a partir de una respuesta positiva a una encuesta o de un comentario específico que el usuario haya añadido después de la resolución.

Capturar

Identifique las marcas de tiempo de los eventos de confirmación del usuario, como un cambio de estado iniciado por este o una respuesta vinculada a una encuesta.

Tipo de evento inferred
SLA incumplido
Se ha incumplido un acuerdo de nivel de servicio basado en el tiempo, como el tiempo de respuesta o de resolución. Se trata de un evento calculado, no de una acción manual del usuario.
Por qué es importante

El seguimiento de los incumplimientos de los SLA es esencial para elaborar informes de cumplimiento e identificar las solicitudes que no se atienden a tiempo.

Dónde obtenerlo

Algunos sistemas registran este evento de forma explícita. De lo contrario, debe calcularse comparando las marcas de tiempo de resolución con las marcas de tiempo objetivo del SLA.

Capturar

Compare la fecha y hora de resolución o respuesta con la fecha límite del SLA definida. Si la resolución se produce después, genere este evento.

Tipo de evento calculated
Solicitud aprobada
La parte correspondiente ha aprobado formalmente la solicitud de servicio. Esta decisión permite que el proceso de cumplimiento avance a la siguiente etapa.
Por qué es importante

Este es un hito importante que marca el fin del subproceso de aprobación. El tiempo entre «Aprobación solicitada» y «Solicitud aprobada» es un KPI crítico.

Dónde obtenerlo

Este evento suele encontrarse en un registro de aprobaciones o inferirse a partir de un cambio de estado de «Pendiente de aprobación» a un estado activo.

Capturar

Utilice la marca de tiempo del registro de aprobación o del evento de cambio de estado en el registro de auditoría de la solicitud.

Tipo de evento explicit
Solicitud de servicio cancelada
La solicitud de servicio se ha retirado antes de completar su atención. La cancelación puede iniciarla el solicitante o la mesa de ayuda.
Por qué es importante

Este es un final alternativo del proceso que no culmina con éxito. Analizar las cancelaciones ayuda a comprender por qué las solicitudes dejan de ser necesarias o se crearon por error.

Dónde obtenerlo

Por lo general, se registra en el historial de estados de la solicitud como un cambio explícito a «Cancelada» o «Retirada».

Capturar

Registre la marca de tiempo del momento en que el estado cambia a «Cancelada».

Tipo de evento explicit
Solicitud reasignada
La responsabilidad de la solicitud de servicio se ha transferido a otro agente o equipo después de la asignación inicial. Esto suele indicar que la solicitud se asignó al destino equivocado o que se escaló.
Por qué es importante

Las reasignaciones frecuentes pueden indicar problemas en la clasificación inicial, las habilidades de los agentes o la complejidad del proceso, y suelen alargar los tiempos de resolución.

Dónde obtenerlo

Se registra mediante el seguimiento de cualquier cambio en los campos «Responsable» o «Grupo asignado» después de la primera asignación.

Capturar

Registre cada marca de tiempo en la que se actualice el campo de responsable o de grupo de asignación, excepto la de la asignación inicial.

Tipo de evento explicit
Solicitud rechazada
La solicitud de servicio se rechazó formalmente durante la fase de aprobación. Este estado terminal detiene el proceso antes de que comience el trabajo para atender la solicitud.
Por qué es importante

Analizar las solicitudes rechazadas ayuda a comprender los motivos del rechazo y puede revelar problemas en la definición de las solicitudes, las políticas o las expectativas de los usuarios.

Dónde obtenerlo

Por lo general, se registra como un estado específico, como «Rechazada» o «Denegada», en el historial de estados de la solicitud.

Capturar

Registre la marca de tiempo del momento en que el estado de la solicitud cambia a «Rechazada» o a otro estado terminal equivalente.

Tipo de evento explicit
Recomendado Opcional

Guías de extracción

Cómo obtener los datos para Process Mining.

Los métodos de extracción varían según el sistema. Para obtener instrucciones detalladas,

consulte nuestra guía de ETL

o seleccione un proceso y un sistema específicos.

¿Todo listo para comenzar?

Comience a optimizar el proceso de solicitudes de servicio. Elija una guía de extracción específica para su sistema o utilice este Template genérico como punto de partida flexible para cualquier fuente de datos.

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

Detecte ineficiencias y reduzca los tiempos de resolución con información útil para la acción.

Comience hoy su prueba gratuita.

No se requiere tarjeta de crédito