Plantilla de Datos: Gestión de Incidencias

El Incident ID es un código alfanumérico único que distingue un incidente de todos los demás dentro del sistema. Se genera al crear un nuevo incidente y permanece constante hasta que el incidente se archiva o elimina permanentemente.

En Process Mining, el Incident ID es la piedra angular del análisis, sirviendo como Case ID. Permite que el software ensamble todos los eventos, cambios de estado y actividades relacionadas en una única y cohesiva instancia de proceso. Al agrupar todos los eventos bajo un Incident ID común, los analistas pueden mapear con precisión el recorrido de principio a fin de cada incidente, desde su informe inicial hasta su resolución y cierre final.

Es esencial para vincular todas las actividades y eventos relacionados y reconstruir el ciclo de vida del incidente de principio a fin para el Process Mining.

Esta es la clave principal de un incidente y se encuentra típicamente en el encabezado o registro principal de cada tabla u objeto de incidente.

El Nombre de la Actividad describe un paso o tarea distinta realizada como parte del proceso de gestión de incidentes. Estas actividades representan los bloques de construcción del mapa de procesos y pueden incluir eventos de sistema automatizados, como 'Incumplimiento de SLA Detectado', o acciones manuales de usuario, como 'Agente Asignado' o 'Solución Provisional Proporcionada'.

Para el análisis de Process Mining, este atributo es fundamental. Define los nodos en el grafo del proceso, permitiendo a los analistas visualizar el flujo de trabajo, identificar rutas comunes, descubrir cuellos de botella y analizar desviaciones del procedimiento estándar. La granularidad y claridad de los nombres de las actividades impactan directamente la calidad y profundidad de los insights que se pueden derivar.

Este atributo define los pasos en el proceso, permitiendo la visualización y el análisis del flujo del ciclo de vida del incidente.

A menudo se deriva de una combinación de registros de eventos, pistas de auditoría, registros de cambio de estado o campos de descripción de tareas dentro del sistema de gestión de incidentes.

El Event Timestamp marca el momento exacto en que ocurrió una actividad. Cada actividad dentro del ciclo de vida de un incidente debe tener un timestamp correspondiente para establecer una secuencia cronológica de eventos.

Este atributo es crítico para cualquier análisis de Process Mining basado en el tiempo. Permite el cálculo de los tiempos de ciclo entre actividades, la duración de pasos específicos y el tiempo total de resolución de incidentes. Al analizar los timestamps, las organizaciones pueden identificar cuellos de botella, medir el cumplimiento de los SLA y comprender cómo cambia el rendimiento del proceso con el tiempo. Es la base para calcular indicadores clave de rendimiento como el Tiempo Promedio de Resolución.

Proporciona el orden cronológico de los eventos, lo cual es esencial para calcular duraciones, identificar cuellos de botella y analizar el rendimiento del proceso a lo largo del tiempo.

Se encuentra en registros de eventos, tablas de historial de auditoría, o como 'última modificación' o 'fecha de creación' en registros relacionados específicos.

El atributo de Sistema Fuente identifica el origen de los datos. En entornos con múltiples herramientas ITSM o sistemas integrados, este campo ayuda a distinguir registros de diferentes fuentes.

Aunque no se utiliza directamente para dibujar el mapa de procesos, este atributo es valioso para la validación y gobernanza de datos. Ayuda a los analistas a rastrear los datos hasta su origen, comprender posibles discrepancias entre sistemas y segmentar el análisis. Por ejemplo, se podría comparar los procesos de gestión de incidentes implementados en dos sistemas diferentes, como ServiceNow y Jira, dentro de la misma organización.

Proporciona contexto para el origen de los datos, lo cual es crucial para la validación de datos, la resolución de problemas y el análisis comparativo en entornos multisistema.

Este es a menudo un valor estático añadido durante el proceso de extracción de datos o un campo disponible en las tablas del sistema de origen.

El timestamp de la Última Actualización de Datos especifica cuándo se extrajeron o sincronizaron los datos más recientemente del sistema fuente. Este es un campo de metadatos que refleja la actualidad de los datos que se están analizando.

En el análisis de Process Mining, este atributo es importante para comprender la puntualidad de los insights generados. Ayuda a los usuarios a saber si están viendo información en tiempo real o una instantánea de un momento anterior. Este contexto es vital para la supervisión operativa y para garantizar que las decisiones se basen en datos actuales y relevantes.

Indica la frescura de los datos, asegurando que los analistas comprendan cuán actual es su análisis de proceso.

Este valor se genera y sella típicamente en cada registro durante el proceso de extracción, transformación y carga (ETL) de datos.

El Agente Asignado identifica a la persona específica responsable de un incidente. Mientras que el Grupo Asignado apunta al equipo, el agente es el ejecutor individual que trabaja en la resolución.

Este atributo permite un nivel más granular de análisis de rendimiento y carga de trabajo. Al rastrear las asignaciones a nivel de agente, los gerentes pueden evaluar la productividad individual, identificar necesidades de capacitación y asegurar una distribución equilibrada del trabajo. En el Process Mining, puede revelar patrones complejos de reasignación que podrían estar ocultos a nivel de grupo y ayuda a comprender las contribuciones individuales a los tiempos de resolución.

Permite un análisis detallado de la carga de trabajo individual, el rendimiento y los patrones de reasignación dentro o entre equipos.

Se encuentra en el registro principal del incidente; este campo se actualiza cuando un agente asume la propiedad o se le asigna el incidente.

El Canal de Notificación indica la fuente del envío del incidente. Este atributo rastrea cómo los usuarios interactúan con la función de soporte, ya sea a través de métodos de contacto directo como llamadas telefónicas o métodos automatizados como alertas de monitoreo del sistema.

Analizar el proceso basándose en el canal de notificación puede revelar diferencias importantes en la eficiencia. Por ejemplo, los incidentes reportados a través de un portal de autoservicio podrían resolverse más rápido porque a menudo contienen información más estructurada de antemano. Este análisis ayuda a las organizaciones a optimizar sus canales de soporte y fomentar el uso de métodos más eficientes.

Ayuda a analizar la eficiencia y las rutas de resolución de incidentes basándose en su origen, lo que puede informar la estrategia de canales y la asignación de recursos.

Esta información se captura generalmente de forma automática o es seleccionada por el agente cuando se crea un incidente.

La Categoría de Incidente proporciona una forma estructurada de clasificar los incidentes según su naturaleza. Típicamente, es un campo jerárquico que permite una clasificación progresivamente más detallada, ayudando a organizar los incidentes en grupos lógicos para informes y análisis.

La categorización es vital para el análisis de la causa raíz y de tendencias. Al analizar los mapas de procesos filtrados por categoría, las organizaciones pueden identificar problemas recurrentes y patrones asociados con tipos específicos de incidentes. Por ejemplo, el proceso de resolución para un incidente de 'Software' podría verse muy diferente al de un incidente de 'Hardware'. Estos datos impulsan KPIs como la Precisión de la Categorización Inicial y la Tasa de Incidentes Recurrentes.

Es esencial para el análisis de la causa raíz, la identificación de tendencias en incidentes recurrentes y la comprensión de cómo se manejan los diferentes tipos de problemas.

Este es un conjunto de campos estándar, a menudo obligatorios, en el registro del incidente utilizados para la clasificación.

El Estado del Incidente indica la etapa de un incidente en un momento específico. Proporciona una vista de alto nivel de dónde se encuentra el incidente en el proceso de resolución. Los estados comunes incluyen nuevo, asignado, en progreso, pendiente, resuelto y cerrado.

Este atributo es fundamental para el análisis de procesos, ya que los cambios de estado a menudo definen las actividades en el mapa de procesos. Analizar el tiempo que se pasa en cada estado ayuda a identificar cuellos de botella, como incidentes que esperan durante largos períodos en un estado 'Pendiente'. También se utiliza para calcular el backlog de incidentes abiertos y rastrear el progreso hacia la resolución.

Es clave para comprender el progreso del incidente y a menudo se utiliza para generar actividades para el mapa de proceso. Analizar el tiempo dedicado a cada estado ayuda a localizar los retrasos.

Típicamente disponible como un campo principal en el registro principal del incidente o en el registro de historial del incidente.

El Grupo Asignado indica qué equipo es responsable del incidente en un momento dado. Los incidentes a menudo se enrutan entre diferentes grupos, como la Mesa de Ayuda de Nivel 1, un equipo de Red de Nivel 2 o un equipo de Soporte de Aplicaciones de Nivel 3.

Este atributo es esencial para el análisis de traspaso y carga de trabajo. El Process Mining puede usar estos datos para visualizar el flujo de incidentes entre equipos, medir el tiempo dedicado en la cola de cada equipo e identificar cuellos de botella causados por reasignaciones frecuentes. Ayuda a responder preguntas sobre la eficiencia y colaboración del equipo, formando la base para el dashboard de Análisis de Traspasos y Reasignaciones.

Es fundamental para analizar los traspasos entre equipos, medir los tiempos de espera en cola y comprender el rendimiento y la distribución de la carga de trabajo específicos de cada equipo.

Esta información se almacena típicamente en el registro del incidente y se actualiza cada vez que el incidente es asignado a un nuevo equipo.

El Método de Resolución describe el resultado del incidente y cómo se resolvió. Esto podría ser un código estandarizado o una descripción de texto libre de las acciones tomadas. Los ejemplos incluyen 'Educación del usuario', 'Parche de software aplicado', 'No se encontró ningún fallo' o 'Incidente duplicado'.

Este atributo proporciona un contexto crucial al final del proceso. En Process Mining, analizar los incidentes por su método de resolución ayuda a comprender la efectividad de diferentes soluciones. Puede resaltar casos que se cierran sin una solución real o identificar patrones de resolución comunes para categorías de incidentes específicas, que luego pueden usarse para construir una base de conocimiento y mejorar las tasas de Resolución en el Primer Contacto.

Proporciona información sobre cómo se están resolviendo los problemas, lo cual es clave para identificar oportunidades de automatización, mejora de la base de conocimientos y capacitación.

Típicamente un campo que es rellenado por el agente de soporte al mover un incidente al estado 'Resuelto' o 'Cerrado'.

La prioridad es un atributo clave utilizado para determinar la importancia relativa de un incidente y la velocidad de respuesta requerida. A menudo se deriva de una combinación del impacto y la urgencia del incidente. Los niveles suelen variar de crítico a bajo.

En el process mining, analizar los incidentes por prioridad permite una comprensión más profunda de cómo el proceso maneja los diferentes niveles de urgencia. Los analistas pueden comparar los tiempos de resolución para incidentes de alta prioridad frente a baja prioridad para ver si se están cumpliendo los SLA y si los recursos se asignan de forma efectiva. Ayuda a responder preguntas como: "¿Estamos realmente gestionando nuestros incidentes más críticos con la mayor rapidez?"

Permite el análisis del rendimiento del proceso para diferentes niveles de urgencia, ayudando a verificar si los incidentes críticos se gestionan más rápido que los no críticos.

Disponible como campo estándar en el registro principal del incidente. Puede definirse manualmente o calcularse automáticamente según el impacto y la urgencia.

La Gravedad define el nivel de impacto que un incidente tiene en el negocio. Responde a la pregunta de cuán serio es el problema, independientemente de su urgencia. Por ejemplo, una interrupción a nivel de sistema sería un incidente de alta gravedad, mientras que un error cosmético menor sería de baja gravedad.

Analizar los incidentes por gravedad ayuda a las organizaciones a comprender qué tipos de problemas causan la mayor interrupción. El Process Mining puede revelar si los incidentes de alta gravedad siguen una ruta de resolución diferente y más ágil. Este atributo es crucial para el análisis de causa raíz y para priorizar los recursos en la gestión proactiva de problemas para evitar la recurrencia de los incidentes más graves.

Ayuda a segmentar los incidentes para comprender si los problemas de alto impacto se resuelven de manera diferente o más eficiente que los de bajo impacto.

Un campo estándar del registro de incidente, a menudo utilizado junto con la urgencia para determinar la prioridad.

El Estado del SLA proporciona una instantánea del rendimiento de un incidente frente a los objetivos de tiempo predefinidos, como el tiempo de respuesta o el tiempo de resolución. Los estados comunes incluyen 'En Progreso', 'En Riesgo' o 'Incumplido'.

Este atributo es una medida directa de la calidad del servicio y una entrada crítica para el dashboard de Visión General del Rendimiento del SLA. En Process Mining, permite la comparación de los flujos de proceso para incidentes incumplidos versus no incumplidos. Esto ayuda a identificar las actividades específicas, los retrasos o los bucles de retrabajo que son los principales impulsores de los fallos del SLA, lo que permite esfuerzos de mejora de procesos específicos.

Es una medida directa del rendimiento frente a los objetivos. Analizar los incidentes que incumplen el SLA ayuda a identificar los fallos del proceso que conducen a una mala prestación del servicio.

Este es típicamente un campo calculado dentro de la herramienta ITSM que se actualiza dinámicamente basándose en la prioridad, antigüedad y reglas de SLA definidas del incidente.

El Conteo de Reasignaciones es una métrica que rastrea el número de traspasos que sufre un incidente durante su ciclo de vida. Un conteo alto a menudo indica ineficiencia, enrutamiento inicial incorrecto o falta de conocimiento dentro de los equipos de soporte.

Este es un atributo poderoso para el análisis de Process Mining. Si bien el Process Mining puede visualizar las reasignaciones, tener un conteo precalculado permite un filtrado y una medición de KPI fáciles. Se utiliza directamente en el dashboard de Análisis de Traspasos y Reasignaciones y ayuda a identificar escenarios de 'ping-pong' donde los tickets se pasan de un lado a otro entre equipos, lo que lleva a tiempos de resolución más largos y frustración del usuario.

Esta métrica cuantifica directamente la ineficiencia del proceso. Un número elevado a menudo se correlaciona con tiempos de resolución más largos e indica problemas con el enrutamiento o las capacidades del equipo.

A menudo disponible como un campo de recuento estándar en el registro del incidente. Si no, se puede derivar contando el número de cambios de asignación en el registro de auditoría del incidente.

El Servicio Afectado vincula un incidente a un componente específico en la infraestructura de TI, como una aplicación de negocio, servidor o dispositivo de red. Esto a menudo está conectado a una Base de Datos de Gestión de Configuración (CMDB).

Este atributo proporciona un contexto de negocio crítico al incidente. En el Process Mining, permite un análisis centrado en la fiabilidad de servicios o activos específicos. Las organizaciones pueden identificar qué servicios generan la mayor cantidad de incidentes, analizar sus procesos de resolución y priorizar los esfuerzos de gestión de problemas para mejorar la estabilidad de servicios de negocio críticos. Es un elemento clave para comprender el impacto de negocio más amplio de los incidentes de TI.

Conecta los incidentes con servicios empresariales o componentes de TI específicos, permitiendo analizar qué servicios son más propensos a problemas y cuál es su impacto.

Típicamente vinculado desde una Base de Datos de Gestión de Configuración (CMDB) o seleccionado de una lista de catálogo de servicios en el formulario de incidente.

El Solicitante es la persona que experimenta el problema e inició el informe del incidente. Puede ser un empleado interno o un cliente externo. El atributo también puede capturar el departamento u organización del solicitante.

Analizar los incidentes por solicitante o departamento del solicitante ayuda a identificar si grupos específicos de usuarios están experimentando más problemas que otros. Esto puede señalar necesidades de capacitación o problemas ambientales localizados. En Process Mining, permite una vista centrada en el usuario del proceso de soporte, ayudando a comprender la experiencia de diferentes cohortes de usuarios.

Permite un análisis centrado en el usuario, ayudando a identificar si ciertos usuarios, departamentos o ubicaciones están generando un número desproporcionado de incidentes.

Un campo estándar del registro de incidente, que normalmente se completa con la persona usuaria que creó el ticket o en cuyo nombre se creó.