Su Template de Data de Gestión de Solicitudes de Servicio
Su Template de Data de Gestión de Solicitudes de Servicio
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de extracción para BMC Helix ITSM
Atributos de Gestión de Solicitudes de Servicio
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
ActivityName
|
El nombre del evento o tarea específica que ocurrió en un punto en el tiempo dentro del ciclo de vida de la solicitud de servicio. | ||
|
Descripción
Este atributo describe un paso específico o cambio de estado en el proceso de solicitud de servicio, como 'Solicitud en Revisión', 'Cumplimiento en Curso' o 'Solicitud de Servicio Resuelta'. Cada actividad representa un único event en el recorrido de extremo a extremo de una solicitud de servicio. Analizar la secuencia y frecuencia de las actividades es el núcleo del Process Mining. Permite el discovery de mapas de procesos, la identificación de bottlenecks y el análisis de variantes de proceso. Comprender qué actividades ocurren, en qué orden y con qué frecuencia es crucial para la optimización del proceso.
Por qué es importante
Las actividades forman los bloques de construcción del mapa de procesos. Su seguimiento permite la visualización y el análisis del flujo del proceso, revelando cómo se realiza el trabajo realmente.
Dónde obtener
Esto se deriva típicamente de cambios en los campos 'Status' y 'Status Reason' en el formulario 'SRM:Request' o en los logs de aplicación de cumplimiento relacionados (p. ej., Incidencia, Orden de Trabajo).
Ejemplos
Solicitud Pendiente de AprobaciónCumplimiento en cursoSolicitud de Servicio ResueltaSolicitud de Servicio Cerrada
|
|||
|
Hora de Inicio
EventStartTime
|
El timestamp que indica cuándo comenzó una actividad o un evento específico. | ||
|
Descripción
Este atributo registra la fecha y hora precisas en que comenzó una actividad. Cada event en el registro, desde el envío inicial hasta el cierre final, debe tener una hora de inicio para establecer la secuencia cronológica del proceso. Esta timestamp es crítica para todo análisis de Process Mining basado en el tiempo. Se utiliza para calcular tiempos de ciclo, duraciones de actividades, tiempos de espera entre pasos y para verificar el cumplimiento del SLA. Permite el discovery de bottlenecks y el análisis del rendimiento del proceso a lo largo del tiempo.
Por qué es importante
La hora de inicio proporciona el orden cronológico de los events, lo cual es esencial para calcular duraciones de procesos, identificar retrasos y comprender la línea de tiempo del proceso.
Dónde obtener
Esto corresponde a los campos de timestamp en los logs de auditoría o tablas de historial de estado asociadas con el formulario 'SRM:Request', como 'Submit Date' para el event inicial.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
ID de Solicitud de Servicio
ServiceRequestId
|
El identificador único para cada solicitud de servicio, que sirve como clave principal para el seguimiento de todo el ciclo de vida. | ||
|
Descripción
El ID de Solicitud de Servicio identifica de forma única cada solicitud de servicio individual enviada por un usuario o sistema. Sirve como el hilo central que vincula todos los events posteriores, desde el registro inicial hasta el cierre final, permitiendo un análisis completo y de extremo a extremo del recorrido de cada solicitud de servicio. En Process Mining, este ID es esencial para reconstruir la secuencia de actividades para cada case. Permite a la herramienta agrupar todos los events relacionados, como 'Solicitud Enviada', 'Solicitud Asignada' y 'Solicitud de Servicio Cerrada', en una única instancia de proceso, formando la base para todo el análisis de procesos.
Por qué es importante
Este es el identificador fundamental del case. Sin él, es imposible rastrear el recorrido de extremo a extremo de una solicitud de servicio, lo que hace imposible el discovery y el análisis del proceso.
Dónde obtener
Este es típicamente el campo 'InstanceId' o 'Request Number' en el formulario 'SRM:Request' de BMC Helix ITSM.
Ejemplos
SR000010572931SR000010572932SR000010572933
|
|||
|
Source System
SourceSystem
|
Identifica el sistema del cual se extrajeron los `datos`. | ||
|
Descripción
Este atributo especifica el origen de los data del proceso. Para esta vista, se establecería estáticamente en 'BMC Helix ITSM' para indicar que todos los events relacionados con las solicitudes de servicio se originaron en este sistema. En entornos con múltiples sistemas integrados, este campo es crucial para comprender la línea de data y particionar los data según su origen. Asegura claridad y trazabilidad, especialmente al fusionar data de diferentes plataformas.
Por qué es importante
Proporciona contexto sobre el origen de los datos, lo cual es importante para la gobernanza de datos, la trazabilidad y la resolución de problemas en entornos multisistema.
Dónde obtener
Este es un valor estático añadido durante el proceso de extracción y transformación de data, no un campo dentro del propio BMC Helix ITSM.
Ejemplos
BMC Helix ITSM
|
|||
|
Última actualización de datos
LastDataUpdate
|
La timestamp de la última actualización de los datos para este proceso desde el sistema de origen. | ||
|
Descripción
Este atributo indica la fecha y hora de la extracción de data más reciente de BMC Helix ITSM. Proporciona a los usuarios contexto sobre la actualidad de los data que están analizando, asegurando que sean conscientes del período de tiempo cubierto por el análisis. Este es un atributo de metadatos crítico para cualquier dashboard o análisis de Process Mining. Permite a los usuarios comprender si los insights se basan en data casi en tiempo real o en una instantánea histórica, lo que afecta la validez y relevancia de las conclusiones extraídas.
Por qué es importante
Informa a los usuarios sobre la puntualidad de los datos, lo cual es esencial para tomar decisiones basadas en la información más actualizada disponible sobre el rendimiento del proceso.
Dónde obtener
Esta timestamp se genera y añade durante el proceso de extracción y carga de data.
Ejemplos
2024-05-21T08:00:00Z
|
|||
|
Agente Asignado
AssignedAgent
|
El usuario individual actualmente asignado para trabajar en la solicitud de servicio. | ||
|
Descripción
Este atributo identifica al agente de TI o miembro del personal de soporte específico responsable de la solicitud en un momento dado. Los cambios en este campo a lo largo del ciclo de vida de una única solicitud indican una transferencia o reasignación. Este atributo es crucial para el rendimiento del agente y el análisis de la carga de trabajo. Permite rastrear cuántas solicitudes maneja cada agente, su tiempo promedio de resolución y la frecuencia de reasignaciones. Estos data respaldan la gestión de recursos y la identificación de oportunidades de capacitación.
Por qué es importante
El seguimiento del agente asignado es esencial para analizar las transferencias, medir el rendimiento individual y comprender la distribución de la carga de trabajo en todo el equipo de soporte.
Dónde obtener
Esto corresponde al campo 'Assignee' o 'Assigned To' en el registro de cumplimiento (p. ej., Orden de Trabajo, Incidencia) asociado con la solicitud de servicio.
Ejemplos
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Equipo asignado
AssignedTeam
|
El grupo de soporte o equipo actualmente asignado a la solicitud de servicio. | ||
|
Descripción
Este atributo identifica al grupo funcional responsable de manejar la solicitud, como 'Mesa de Ayuda', 'Equipo de Red' o 'Administración de Bases de Datos'. Un cambio en este campo significa una transferencia de responsabilidad entre equipos. El análisis basado en el equipo asignado ayuda a identificar bottlenecks a nivel de equipo, analizar las transferencias entre equipos y evaluar la eficiencia de diferentes grupos de soporte. Es clave para los dashboards de Retrabajo y Reasignación de Solicitudes y Eficiencia de Triaje, revelando patrones en cómo se enruta el trabajo a través de la organización.
Por qué es importante
Permite el análisis del flujo de procesos entre diferentes grupos funcionales, ayudando a identificar ineficiencias de enrutamiento y a medir el rendimiento a nivel de equipo.
Dónde obtener
Esto corresponde al campo 'Assigned Group' en el registro de cumplimiento (p. ej., Orden de Trabajo, Incidencia) asociado con la solicitud de servicio.
Ejemplos
Mesa de AyudaSoporte de infraestructuraSoporte de Aplicaciones Nivel 2
|
|||
|
Estado de Solicitud
RequestStatus
|
El estado de la solicitud de servicio en el momento del event, como 'En Curso', 'Pendiente' o 'Cerrada'. | ||
|
Descripción
Este atributo captura el estado de la solicitud de servicio en diferentes puntos de su ciclo de vida. El estado proporciona contexto para cada actividad y a menudo es la fuente de la que se deriva el atributo 'Actividad'. El análisis por estado ayuda a comprender cuánto tiempo pasan las solicitudes en ciertos estados, como 'Pendiente del Cliente' o 'Esperando Aprobación'. Esto es esencial para identificar bottlenecks y retrasos causados por dependencias externas o colas internas. Apoya directamente el dashboard de Identificación de Bottlenecks.
Por qué es importante
Proporciona una instantánea del estado de la solicitud, permitiendo el análisis del tiempo transcurrido en estados de espera versus estados activos, lo cual es clave para identificar cuellos de botella.
Dónde obtener
Este es el campo 'Status' en el formulario 'SRM:Request'. Los valores históricos se pueden encontrar en el audit log.
Ejemplos
PlanificaciónEn ProgresoPendienteResueltoCerrado
|
|||
|
Hora de Finalización
EventEndTime
|
La marca de tiempo que indica cuándo se completó una actividad o evento específico. | ||
|
Descripción
La End Time (Hora de Finalización) marca la conclusión de una actividad. Si bien muchas actividades en los sistemas ITSM son cambios de estado instantáneos, algunas tienen una duración medible. Tener una End Time permite un cálculo preciso de la duración de dichas actividades. En el análisis, la End Time se utiliza junto con la Start Time para calcular el tiempo de procesamiento de actividades individuales. Esto ayuda a identificar qué tareas específicas, no solo el tiempo de espera entre ellas, están consumiendo la mayor parte del tiempo en el proceso.
Por qué es importante
Permite el cálculo de los tiempos de procesamiento de actividades, lo cual es crucial para identificar pasos ineficientes y comprender dónde dedican su tiempo los recursos.
Dónde obtener
Esto puede derivarse. La End Time de una actividad es a menudo la Start Time de la siguiente actividad secuencial para el mismo case. Para la actividad final, sería la timestamp de resolución o cierre.
Ejemplos
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
|
|||
|
Prioridad
Priority
|
El nivel de prioridad asignado a la solicitud de servicio, indicando su impacto comercial y urgencia. | ||
|
Descripción
La prioridad determina el orden y la velocidad con la que deben gestionarse las solicitudes. Los valores comunes incluyen 'Crítica', 'Alta', 'Media' y 'Baja'. Esta asignación a menudo se basa en una combinación del impacto de la solicitud en el negocio y su urgencia. Analizar por prioridad es esencial para evaluar si las solicitudes de alta prioridad se procesan más rápido que las de baja prioridad. Es una dimensión clave en los dashboards para el tiempo de resolución y el cumplimiento de SLA, ayudando a asegurar que los recursos se asignen apropiadamente a las necesidades comerciales más críticas.
Por qué es importante
Ayuda a evaluar si el proceso prioriza correctamente el trabajo y cumple con los niveles de servicio esperados para solicitudes con diferentes niveles de impacto en el negocio.
Dónde obtener
Este es el campo 'Priority' en el formulario 'SRM:Request'.
Ejemplos
CríticoAltoMedioBajo
|
|||
|
Tipo de Servicio
ServiceType
|
La 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 Nuevo Software', 'Restablecimiento de Contraseña' o 'Incorporar Nuevo Empleado'. Es una dimensión fundamental para filtrar y segmentar los datos del proceso. En el análisis de procesos, este atributo se utiliza para comparar el rendimiento de diferentes tipos de solicitudes. Ayuda a responder preguntas como, '¿Qué tipos de servicio tardan más en resolverse?' o '¿Qué tipos de servicio tienen más retrabajos?'. Esto es crítico para los dashboards de Tiempo de Resolución y Cumplimiento de SLA.
Por qué es importante
Permite la segmentación de solicitudes de servicio para comparar flujos de proceso, identificar problemas específicos de tipo y adaptar los esfuerzos de optimización de manera efectiva.
Dónde obtener
Estos data a menudo se encuentran en el campo 'Título' o en un campo de categorización del formulario 'SRM:Request', derivados del servicio seleccionado en el catálogo.
Ejemplos
Nueva solicitud de hardwareSolicitud de Acceso a SoftwareConfiguración de Acceso VPN
|
|||
|
¿Es Retrabajo?
IsRework
|
Un indicador booleano que indica si una solicitud de servicio ha pasado por un retrabajo, como volver a una etapa anterior. | ||
|
Descripción
Este flag identifica las solicitudes de servicio que han experimentado un bucle o retrabajo en su flujo de proceso. Por ejemplo, una solicitud que pasa de 'Cumplimiento en Curso' de nuevo a 'Solicitud en Revisión' se consideraría retrabajo. La definición exacta depende de la lógica del proceso de negocio. Este atributo apoya directamente 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 las causas comunes, como una evaluación inicial incorrecta o información incompleta, lo que lleva a ineficiencias en el proceso.
Por qué es importante
Cuantifica la ineficiencia del proceso al señalar los casos que se desvían de la 'ruta feliz', ayudando a identificar las causas raíz de los bucles y el trabajo repetido.
Dónde obtener
Este es un atributo calculado derivado de la secuencia de actividades en el registro de eventos. Se necesita lógica para detectar movimientos hacia atrás en el flujo del proceso.
Ejemplos
truefalse
|
|||
|
¿Se incumplió el SLA?
IsSlaBreached
|
Un indicador booleano que indica si la solicitud de servicio se resolvió después de la fecha objetivo de su SLA. | ||
|
Descripción
Este flag calculado se establece en true si la timestamp de resolución final de la solicitud de servicio es posterior a su 'SLA Target Date'. Proporciona un resultado binario simple para el rendimiento del SLA por solicitud. Este atributo es esencial para el dashboard de Visión General de Cumplimiento de SLA y el KPI de Tasa de Adherencia al SLA. Permite una fácil agregación para calcular las tasas de cumplimiento generales y permite filtrar para analizar las características del proceso de las solicitudes incumplidas frente a las conformes, ayudando a identificar las causas raíz de los fallos del SLA.
Por qué es importante
Simplifica el análisis del rendimiento de los SLA convirtiendo una comparación de marcas de tiempo en un simple indicador booleano, facilitando la medición y visualización de las tasas de cumplimiento.
Dónde obtener
Este es un campo calculado. La lógica es: SI 'Resolution Timestamp' > 'SlaTargetDate' ENTONCES true SINO false.
Ejemplos
truefalse
|
|||
|
Canal de Presentación
SubmissionChannel
|
El método o canal a través del cual se presentó 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 self-service, correo electrónico, llamada telefónica a la mesa de servicio o alerta de sistema automatizada. Diferentes canales pueden conducir a diferentes variantes de proceso y tiempos de resolución. El análisis del proceso por canal de envío puede revelar ineficiencias o mejores prácticas asociadas con métodos de entrada específicos. Por ejemplo, las solicitudes enviadas a través del portal de self-service pueden resolverse más rápido debido a una mejor calidad de los data iniciales, mientras que las de correo electrónico pueden requerir un triaje más manual.
Por qué es importante
Ayuda a comprender cómo el método de entrada afecta la eficiencia del proceso, la calidad de los datos y el tiempo de ciclo general, permitiendo mejoras dirigidas en canales específicos.
Dónde obtener
Esto a menudo puede inferirse de campos como 'Tipo de Cliente' o 'Fuente Informada' en el formulario 'SRM:Request' o en los tickets de cumplimiento asociados.
Ejemplos
Portal de AutoservicioEmailTeléfonoGenerado por el Sistema
|
|||
|
Categoría de Resolución
ResolutionCategory
|
La clasificación de la solución proporcionada para resolver la solicitud. | ||
|
Descripción
Este atributo proporciona una categorización estructurada de cómo se resolvió una solicitud, como 'Corrección de Software', 'Capacitación de Usuario' o 'Corrección de Data'. Va más allá de un simple código de cierre para describir la naturaleza de la resolución. Esto 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 verificar la consistencia. El análisis de las categorías de resolución ayuda a identificar tendencias en los problemas e informa la gestión proactiva de problemas, por ejemplo, si muchas solicitudes se resuelven mediante capacitación de usuarios.
Por qué es importante
Ofrece información sobre la naturaleza de las soluciones, ayudando a identificar tendencias en problemas recurrentes y oportunidades para la gestión proactiva de problemas o la capacitación de usuarios.
Dónde obtener
Esta información forma parte de los campos de categorización operativa y de producto en el ticket de cumplimiento, a menudo etiquetados como 'Categoría de Resolución'.
Ejemplos
Administración de cuentasFallo de HardwareActualización de SoftwareInformación Proporcionada
|
|||
|
Código de Cierre
CloseCode
|
Un código que indica el resultado final o el motivo del cierre de la solicitud de servicio. | ||
|
Descripción
El Código de Cierre proporciona una forma estandarizada de clasificar la resolución de una solicitud de servicio. Los ejemplos incluyen 'Resuelta por Mesa de Servicio', 'Cancelada por el Usuario' o 'Solicitud Duplicada'. El análisis de los códigos de cierre ayuda a comprender los resultados comunes de las solicitudes. Puede resaltar problemas como un alto número de solicitudes canceladas por los usuarios, lo que podría indicar un proceso prolongado, o muchos duplicados, lo que podría señalar un problema de sistema o comunicación. Este atributo es compatible con 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, permitiendo el análisis de la efectividad de la resolución y las razones de la no finalización o cancelación.
Dónde obtener
Esta información se encuentra típicamente en un campo de 'Resolución' o 'Código de Cierre' en el ticket de cumplimiento asociado con la solicitud de servicio.
Ejemplos
ExitosoCancelado por el usuarioYa no requeridoResolución automatizada
|
|||
|
Departamento del Solicitante
RequestorDepartment
|
El departamento o unidad de negocio del usuario que envió la solicitud. | ||
|
Descripción
Este atributo identifica el departamento organizacional de la persona que solicita el servicio, como 'Finanzas', 'Recursos Humanos' o 'TI'. Esta información se obtiene típicamente del perfil del usuario en el sistema. Segmentar el análisis del proceso por departamento permite identificar necesidades específicas del departamento, patrones de solicitud y áreas potenciales para capacitación dirigida o mejoras del servicio. Puede ayudar a responder preguntas como, '¿Experimenta el departamento de Finanzas tiempos de espera más largos para sus solicitudes?'.
Por qué es importante
Permite el análisis del consumo de servicios y el rendimiento del proceso por unidad de negocio, lo que puede resaltar problemas o tendencias específicos del departamento.
Dónde obtener
Esta información se recupera generalmente del perfil del usuario asociado con el usuario 'Requested For' en el formulario 'SRM:Request'.
Ejemplos
FinanzasVentasRecursos HumanosTecnología de la Información
|
|||
|
Está Escalado
IsEscalated
|
Un indicador booleano que indica si la solicitud de servicio ha sido escalada. | ||
|
Descripción
Este flag se establece en true si una solicitud de servicio ha sido objeto de una escalación funcional o jerárquica. Una escalación típicamente ocurre cuando una solicitud no progresa como se espera, está a punto de incumplir un SLA o requiere una autoridad superior para aprobación o acción. Este atributo es clave para el dashboard de Análisis de Eficiencia de Escalación de Solicitudes. Permite filtrar y analizar las rutas de proceso de las solicitudes escaladas para comprender qué las desencadena, cuánto tiempo tardan en resolverse después de la escalación y cuán efectivo es el proceso de escalación.
Por qué es importante
Permite aislar y analizar el subconjunto de solicitudes que requirieron escalada, ayudando a identificar debilidades en el proceso estándar o disparadores de problemas complejos.
Dónde obtener
Esto típicamente no es un solo campo. Se deriva al verificar actividades específicas relacionadas con la escalación en el audit log o cambios en la prioridad o asignación que siguen un protocolo de escalación.
Ejemplos
truefalse
|
|||
|
Fecha Objetivo de SLA
SlaTargetDate
|
La fecha y hora en la que se espera que la solicitud de servicio sea resuelta según su Acuerdo de Nivel de Servicio (SLA). | ||
|
Descripción
La Fecha Objetivo de SLA es una timestamp calculada que representa la fecha límite para completar la solicitud de servicio. Se determina por las reglas del acuerdo de servicio, que a menudo tienen en cuenta factores como la prioridad y el tipo de la solicitud. Este atributo es fundamental para el dashboard de Resumen de Cumplimiento de SLA. Sirve como el punto de referencia contra el cual se mide el tiempo de resolución real. Al comparar la 'EventEndTime' de la actividad de resolución final con esta fecha objetivo, podemos determinar si se cumplió el compromiso de servicio.
Por qué es importante
Este es el punto de referencia principal para medir el rendimiento del servicio frente a los compromisos, lo que lo hace esencial para el monitoreo y los informes de cumplimiento del SLA.
Dónde obtener
Esta fecha es calculada y almacenada por el módulo de Gestión de Nivel de Servicio (SLM) y se puede encontrar en los formularios SLM relacionados vinculados a la solicitud de servicio.
Ejemplos
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
|
|||
|
Recuento de Traspasos
HandoffCount
|
El número total de veces que una solicitud de servicio fue reasignada entre diferentes agentes o equipos. | ||
|
Descripción
Esta métrica calculada cuenta el número de veces que el 'AssignedAgent' o 'AssignedTeam' cambia para una sola solicitud de servicio. Un alto número de transferencias puede indicar fragmentación del proceso, falta de resolución en la primera llamada o enrutamiento ineficiente. Este atributo es la base para el KPI de Transferencias Promedio de Agentes por Solicitud y se utiliza en el dashboard de Retrabajo y Reasignación de Solicitudes. El análisis de cases con un alto número de transferencias puede revelar oportunidades para mejorar el triaje, proporcionar mejor capacitación o agilizar el proceso de resolución para reducir retrasos y mejorar la satisfacción del cliente.
Por qué es importante
Mide la fragmentación del proceso y la sobrecarga de comunicación. Un alto número de traspasos a menudo se correlaciona con tiempos de resolución más largos y una menor eficiencia del proceso.
Dónde obtener
Esta es una métrica calculada derivada al contar el número de valores distintos en el atributo 'AssignedAgent' o 'AssignedTeam' para cada ID de Solicitud de Servicio único.
Ejemplos
0135
|
|||
|
Tiempo de Ciclo
CycleTime
|
El tiempo total transcurrido desde la creación de la solicitud de servicio hasta su resolución final. | ||
|
Descripción
El tiempo de ciclo, también conocido como duración de extremo a extremo, mide la vida útil total de una solicitud de servicio. Se calcula como la diferencia entre la marca de tiempo del primer evento (por ejemplo, 'Solicitud de servicio enviada') y el último evento de resolución (por ejemplo, 'Solicitud de servicio resuelta'). Este es uno de los KPI más fundamentales en Process Mining, que apoya directamente el dashboard de tiempo de resolución de solicitudes de servicio. Analizar el tiempo de ciclo promedio, y segmentarlo por dimensiones como el tipo de servicio o la prioridad, revela la eficiencia general del proceso y destaca las áreas que están tardando demasiado.
Por qué es importante
Esta es una medida principal de la eficiencia del proceso. Comprender y reducir el tiempo de ciclo es a menudo un objetivo clave de las iniciativas de mejora de procesos.
Dónde obtener
Esta es una métrica calculada. Se deriva restando la 'Submit Date' de la 'Closed Date' o 'Resolved Date' para cada ID de Solicitud de Servicio único.
Ejemplos
2 días 4 horas8 horas 30 minutos15 días
|
|||
Actividades de Gestión de Solicitudes de Servicio
| Actividad | Descripción | ||
|---|---|---|---|
|
Cumplimiento en curso
|
El agente o equipo asignado ha comenzado a trabajar activamente en la ejecución de la solicitud de servicio. Esto indica que la solicitud ha pasado de una cola a un estado de trabajo activo. | ||
|
Por qué es importante
Marca el inicio del trabajo de cumplimiento de valor añadido. Analizar el tiempo dedicado a esta fase ayuda a comprender la productividad de los recursos y la complejidad del cumplimiento.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a 'En Progreso'.
Capturar
Timestamp del event de actualización donde el campo 'Status' de SRM:Request cambia a 'En Curso'.
Tipo de evento
inferred
|
|||
|
Solicitud Asignada
|
La solicitud de servicio ha sido asignada a un agente o equipo de cumplimiento específico responsable de completar el trabajo. Esto marca el final de la fase de triaje. | ||
|
Por qué es importante
Este hito es crítico para medir el tiempo de triaje y analizar la carga de trabajo de los agentes. Las reasignaciones frecuentes pueden indicar problemas de enrutamiento o brechas de habilidades.
Dónde obtener
Este event puede capturarse explícitamente del audit log de los campos 'Assigned Group' o 'Assignee' en el SRM:Request o en los formularios de aplicación de cumplimiento relacionados (p. ej., WOI:WorkOrder).
Capturar
Timestamp del audit log que muestra que se ha establecido por primera vez un valor no nulo en el campo 'Assignee'.
Tipo de evento
explicit
|
|||
|
Solicitud de Servicio Cancelada
|
La solicitud de servicio ha sido retirada, ya sea por el solicitante o por la mesa de servicio, antes de que se completara el cumplimiento. Este es un estado terminal para la solicitud. | ||
|
Por qué es importante
El seguimiento de las cancelaciones ayuda a identificar patrones, como usuarios que envían solicitudes incorrectas o servicios que ya no son necesarios, lo que puede informar mejoras en el catálogo de servicios.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a 'Cancelado'.
Capturar
Timestamp del event de actualización donde 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 se mueve a un estado de solo lectura y archivado. Esto ocurre después de la resolución y de que haya transcurrido cualquier período de confirmación. | ||
|
Por qué es importante
Esta actividad representa el fin definitivo del proceso. El tiempo entre 'Resuelta' y 'Cerrada' puede resaltar ineficiencias en el procedimiento de cierre.
Dónde obtener
Inferido del cambio de estado final en el formulario SRM:Request a 'Cerrado'.
Capturar
Timestamp del event de actualización donde 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 nueva entrada en el formulario SRM:Request con un estado inicial, típicamente 'Enviada'. | ||
|
Por qué es importante
Este es el punto de partida para cada case de solicitud de servicio, esencial para medir la duración total del ciclo de vida y analizar los volúmenes de entrada de solicitudes.
Dónde obtener
Este event se infiere de la timestamp de creación y el estado inicial (p. ej., 'Enviada') de un registro en el formulario SRM:Request.
Capturar
Identifique la marca de tiempo de creación para un nuevo ID de solicitud de servicio en el formulario SRM:Request cuando el estado es 'Enviado'.
Tipo de evento
inferred
|
|||
|
Solicitud de Servicio Resuelta
|
El cumplimiento de la solicitud de servicio está completo y la resolución ha sido comunicada al solicitante. La solicitud espera confirmación final o se autocerrará después de un período establecido. | ||
|
Por qué es importante
Un hito crítico que marca el final del ciclo de entrega del servicio. Es el punto final principal para medir el tiempo de resolución y el cumplimiento de los SLA.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a 'Resuelto' o 'Completado'.
Capturar
Timestamp del event de actualización donde el campo 'Status' de SRM:Request cambia a 'Resuelta' o 'Completada'.
Tipo de evento
inferred
|
|||
|
Información solicitada al usuario
|
El agente de cumplimiento requiere información adicional del solicitante para continuar con el trabajo. La solicitud se suele poner en estado 'Pendiente'. | ||
|
Por qué es importante
Esta actividad es crucial para calcular el 'Tiempo de Espera de Información Externa', identificando con qué frecuencia las solicitudes se estancan debido a información incompleta.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a 'Pendiente' con un motivo de estado como 'Retención por parte del cliente' o 'Esperando información'.
Capturar
Timestamp del cambio de estado a 'Pendiente' combinado con un motivo de estado específico.
Tipo de evento
inferred
|
|||
|
Resolución Confirmada por el Usuario
|
El solicitante ha confirmado activamente que el servicio se ha entregado satisfactoriamente y la solicitud está resuelta. Esto a menudo desencadena el cierre final de la solicitud. | ||
|
Por qué es importante
Proporciona un indicador claro de la satisfacción del cliente y concluye formalmente la interacción de servicio. Separa la resolución del proceso de la aceptación del cliente.
Dónde obtener
Este event podría capturarse en los logs de trabajo o notas de actividad del SRM:Request cuando un usuario confirma a través del portal o correo electrónico. No siempre es un estado discreto.
Capturar
Escanear registros de trabajo (SRM:WorkInfo) en busca de entradas específicas que indiquen la confirmación del usuario o la finalización de encuestas.
Tipo de evento
explicit
|
|||
|
Solicitud Aprobada
|
La solicitud de servicio ha sido aprobada formalmente por la parte requerida, lo que permite que el proceso de cumplimiento continúe. Este event suele seguir un estado de 'Pendiente de Aprobación'. | ||
|
Por qué es importante
Marca el final del subproceso de aprobación y es un hito clave para rastrear cuánto tiempo tardan las aprobaciones y su impacto en el tiempo de resolución general.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request de 'Esperando Aprobación' a un estado posterior como 'Planificación' o 'En Progreso'. La decisión de aprobación en sí se registra en formularios de aprobación relacionados.
Capturar
Timestamp del cambio de estado de 'Pendiente de Aprobación' después de una decisión de aprobación positiva.
Tipo de evento
inferred
|
|||
|
Solicitud en Revisión
|
La solicitud de servicio está pasando por una revisión inicial y un triaje por parte de la mesa de servicio para determinar su naturaleza, prioridad y el equipo de cumplimiento adecuado. Esto se representa típicamente por un cambio de estado en el registro de la solicitud. | ||
|
Por qué es importante
El seguimiento de esta actividad ayuda a medir la eficiencia del triaje e identifica los retrasos entre el envío y la asignación, lo cual es crucial para el KPI de 'Tiempo Promedio de Triaje'.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a un valor como 'En Revisión' o 'Planificación'.
Capturar
Timestamp del event de actualización donde el campo 'Status' de SRM:Request cambia a 'En Revisión'.
Tipo de evento
inferred
|
|||
|
Solicitud Pendiente de Aprobación
|
La solicitud de servicio ha sido enviada a un aprobador o grupo de aprobación designado y está a la espera de una decisión antes de que pueda comenzar el cumplimiento. Este es un paso común para solicitudes que implican costos o derechos de acceso. | ||
|
Por qué es importante
Esta actividad aísla los retrasos relacionados con la aprobación, permitiendo el análisis de los tiempos del ciclo de aprobación y la identificación de bottlenecks en la cadena de aprobación.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a un valor como 'Esperando Aprobación'.
Capturar
Timestamp del event de actualización donde el campo 'Status' de SRM:Request cambia a 'Pendiente de Aprobación'.
Tipo de evento
inferred
|
|||
|
Solicitud Reanudada
|
La solicitud de servicio ha sido retirada de un estado pendiente o de espera, típicamente después de que el usuario proporcionó la información requerida. El agente de cumplimiento reanuda el trabajo en la solicitud. | ||
|
Por qué es importante
Marca el final de un período de espera, permitiendo la medición precisa de los tiempos de espera externos y su impacto en el cumplimiento de los SLA.
Dónde obtener
Inferido cuando el estado de la SRM:Request cambia de 'Pendiente' a 'En Progreso'.
Capturar
Timestamp del event de actualización donde el campo 'Status' de SRM:Request cambia de 'Pendiente' a 'En Curso'.
Tipo de evento
inferred
|
|||
|
Solicitud Rechazada
|
La solicitud de servicio fue denegada durante una fase de aprobación. Este es un estado terminal que detiene el proceso antes de que comience el cumplimiento. | ||
|
Por qué es importante
Analizar las solicitudes rechazadas puede poner de manifiesto problemas con justificaciones de solicitudes, criterios de elegibilidad o políticas de aprobación.
Dónde obtener
Inferido de un cambio de estado en el formulario SRM:Request a 'Rechazado'.
Capturar
Timestamp del event de actualización donde el campo 'Status' de SRM:Request cambia a 'Rechazada'.
Tipo de evento
inferred
|
|||
|
Solución Implementada
|
El trabajo técnico requerido para cumplir con la solicitud de servicio ha sido completado por el agente. La solicitud está ahora lista para la confirmación con el usuario antes de ser formalmente resuelta. | ||
|
Por qué es importante
Esta actividad separa la finalización técnica de la resolución formal, ayudando a identificar cualquier retraso entre la finalización del trabajo y la confirmación del usuario.
Dónde obtener
Esto puede inferirse de un cambio de estado en un ticket de cumplimiento de backend (p. ej., estado de Orden de Trabajo a 'Completada') antes de que la SRM:Request principal se marque como 'Resuelta'.
Capturar
Timestamp cuando un ticket de backend (Orden de Trabajo, Incidencia, etc.) vinculado al SRM:Request se marca como completo.
Tipo de evento
inferred
|
|||