Su Template de datos para la gestión de problemas
Su Template de datos para la gestión de problemas
- Atributos recomendados para el análisis de la causa raíz
- Hitos y actividades clave del proceso
- Guía paso a paso para extraer datos de ServiceNow
Atributos de la gestión de problemas
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
Activity
|
Evento o acción específica realizada en el registro de problema. | ||
|
Descripción
Representa los pasos diferenciados o cambios de estado que se producen durante el ciclo de vida de un registro de problema. Algunos ejemplos son «Problem Record Created», «Root Cause Identified» o «Assigned to Support Group». Este Atributo es fundamental para construir el mapa del proceso y visualizar la secuencia de eventos.
Por qué es importante
Define los nodos del mapa del proceso y permite visualizar el flujo de trabajo y las variantes del proceso.
Dónde obtenerlo
Derivado de las tablas «sys_audit» y «sys_history_line» o de los cambios de estado en la tabla «problem»
Ejemplos
Registro de problema creadoAnálisis completadoEstado cambiado a cerrado
|
|||
|
Marca de tiempo del evento
EventTime
|
Fecha y hora exactas en que se produjo una actividad. | ||
|
Descripción
Registra la marca de tiempo específica en que se registró un cambio o una acción en el sistema. Este dato es fundamental para ordenar cronológicamente las actividades y calcular métricas de duración, como los tiempos de ciclo y los plazos entre los pasos del proceso.
Por qué es importante
Esencial para ordenar los eventos y calcular todos los KPI basados en el tiempo.
Dónde obtenerlo
Campo «sys_created_on» de ServiceNow en las tablas de auditoría o historial
Ejemplos
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
Registro de problema
ProblemNumber
|
Identificador único del registro de problema. | ||
|
Descripción
Clave alfanumérica única asignada a un registro de problema específico en ServiceNow (por ejemplo, PRB000123). Este identificador actúa como hilo central que vincula todas las actividades del proceso, desde el registro inicial hasta el análisis de causas raíz y el cierre definitivo. En el análisis de Process Mining, este Atributo funciona como el ID del caso y permite reconstruir el recorrido completo de la resolución del problema.
Por qué es importante
Es la clave principal para diferenciar casos únicos y agrupar eventos relacionados en el grafo del proceso.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «number»
Ejemplos
PRB004512PRB009823PRB001122
|
|||
|
Sistema de origen
SourceSystem
|
Nombre del sistema del que proceden los datos. | ||
|
Descripción
Identifica la instancia o el entorno específico de ServiceNow del que se extrajeron los datos de gestión de problemas. Resulta especialmente útil en entornos con varios sistemas para realizar un seguimiento del linaje de los datos y gestionar las particularidades de cada sistema en el análisis.
Por qué es importante
Proporciona contexto sobre el origen de los datos, especialmente al combinar datos de varias herramientas de ITSM.
Dónde obtenerlo
Codificado durante la extracción (por ejemplo, «ServiceNow Production»)
Ejemplos
ServiceNow ProdServiceNow EMEA
|
|||
|
Última actualización de datos
LastDataUpdate
|
Marca de tiempo en que se extrajeron los datos o se actualizaron por última vez. | ||
|
Descripción
Indica el grado de actualización del conjunto de datos utilizado para el análisis. Ayuda a los analistas a saber si están consultando datos en tiempo real o una instantánea histórica, algo fundamental para interpretar correctamente los estados de los casos abiertos.
Por qué es importante
Garantiza que los usuarios conozcan el grado de actualización de los datos para elaborar informes operativos precisos.
Dónde obtenerlo
Hora del sistema en el momento de ejecutar el proceso ETL
Ejemplos
2023-11-01T12:00:00Z
|
|||
|
Categoría de causa raíz
RootCauseCategory
|
Clasificación de la causa raíz identificada. | ||
|
Descripción
Clasifica el motivo subyacente del problema, como error de software, error humano o fallo de hardware. Este Atributo alimenta el Dashboard de precisión de la categorización de causas raíz y ayuda a identificar patrones de fallos sistémicos.
Por qué es importante
Permite analizar patrones de fallos para impulsar mejoras estratégicas.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «rca_category» o «u_root_cause_category»
Ejemplos
Defecto de softwareError de configuraciónProblema con el proveedor
|
|||
|
Estado del problema
ProblemState
|
Estado del ciclo de vida del registro de problema. | ||
|
Descripción
Refleja la fase actual del registro de problema, como Open, Root Cause Analysis, Fix in Progress o Closed. Es un factor principal para filtrar y comprender la composición del backlog en el «Aged Problem Record Aging Analysis».
Por qué es importante
Indicador de estado principal utilizado para filtrar casos abiertos y cerrados.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «state»
Ejemplos
NuevoEvaluarAnálisis de causas raízResuelto
|
|||
|
Grupo de soporte
AssignmentGroup
|
Equipo técnico responsable de resolver el problema. | ||
|
Descripción
Designa el grupo o equipo de soporte específico asignado actualmente al problema. Este Atributo es fundamental para el Dashboard de análisis de reasignaciones de grupos de soporte, ya que permite realizar un seguimiento de las transferencias entre equipos e identificar silos organizativos.
Por qué es importante
Esencial para identificar cuellos de botella entre departamentos y analizar la eficiencia de las transferencias.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «assignment_group»
Ejemplos
Operaciones de redAdministradores de bases de datosMesa de servicio
|
|||
|
Número de incidentes relacionados
RelatedIncidentCount
|
Número de incidentes vinculados a este registro de problema. | ||
|
Descripción
Cuantifica el impacto del problema contando el número de incidentes asociados. Los valores elevados en este campo, especialmente en el caso de errores conocidos, alimentan el Dashboard de errores conocidos y recurrencia de incidentes.
Por qué es importante
Mide la magnitud del impacto del problema en los usuarios.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «related_incidents» (el nombre del campo puede variar) o recuento de registros vinculados
Ejemplos
1501200
|
|||
|
Número de reasignaciones
ReassignmentCount
|
Número de veces que el problema se reasignó entre grupos. | ||
|
Descripción
Contador que registra con qué frecuencia ha cambiado el grupo de asignación. Es la fuente directa del KPI «Problem Record Reassignment Count» y ayuda a identificar los efectos de «ping-pong», en los que los tickets pasan de un equipo a otro.
Por qué es importante
Indicador directo de fricción en el proceso y falta de responsabilidad clara.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «reassignment_count»
Ejemplos
0312
|
|||
|
Prioridad
Priority
|
Nivel de prioridad asignado al registro de problema. | ||
|
Descripción
Indica la importancia y la urgencia del problema, normalmente calculadas a partir del impacto y la urgencia. Este Atributo permite segmentar el análisis por criticidad y facilita el Dashboard de supervisión de incumplimientos de SLA y prioridades.
Por qué es importante
Permite segmentar el rendimiento del proceso según la criticidad empresarial.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «priority»
Ejemplos
1 - Crítico2 - Alto3 - Moderado
|
|||
|
Usuario asignado
AssignedTo
|
Persona específica asignada para trabajar en el problema. | ||
|
Descripción
Identifica al usuario responsable actualmente del registro de problema. Analizar este Atributo ayuda a comprender la distribución de la carga de trabajo, el rendimiento individual y los posibles cuellos de botella a nivel de recurso.
Por qué es importante
Clave para analizar la eficiencia de los recursos y la carga de trabajo individual.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «assigned_to»
Ejemplos
Alice SmithBob JonesAdministrador del sistema
|
|||
|
Duración pendiente
PendingDuration
|
Tiempo total que el problema permaneció en estado suspendido o pendiente. | ||
|
Descripción
Agrega el tiempo transcurrido en estados como «Pending Vendor» u «On Hold». Esta métrica se utiliza en el análisis de estados pendientes y tiempos de espera para separar el tiempo de procesamiento interno de las demoras externas.
Por qué es importante
Distingue entre la ineficiencia del equipo y las dependencias externas.
Dónde obtenerlo
Calculado: suma de la duración de los intervalos en los que State = Pending/On Hold
Ejemplos
5 días0 minutos
|
|||
|
Elemento de configuración
ConfigurationItem
|
Activo o servicio específico afectado por el problema. | ||
|
Descripción
Identifica el elemento de configuración (CI) vinculado al registro de problema. Analizarlo ayuda a relacionar los problemas con hardware, software o servicios específicos y facilita el Dashboard de precisión de la categorización de causas raíz.
Por qué es importante
Vincula los problemas del proceso con activos físicos o lógicos específicos.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «cmdb_ci»
Ejemplos
Servidor 01 de SAP ERPServicio de correo electrónico de ExchangeOracle DB Prod
|
|||
|
Es un error conocido
IsKnownError
|
Indicador que señala si el problema está clasificado como error conocido. | ||
|
Descripción
Identifica si el registro de problema se ha convertido en un error conocido o se ha marcado como tal. Es esencial para el análisis de errores conocidos y recurrencia de incidentes, ya que permite comprobar la eficacia del proceso de gestión del conocimiento.
Por qué es importante
Distingue entre investigaciones activas y defectos aceptados con soluciones alternativas.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «known_error»
Ejemplos
truefalse
|
|||
|
Fecha límite del SLA
SlaDueDate
|
Fecha y hora objetivo para resolver el problema según el SLA. | ||
|
Descripción
La marca de tiempo que indica cuándo debe resolverse el problema para cumplir los acuerdos de nivel de servicio. Es la base del Dashboard «Incumplimiento de SLA y supervisión de prioridades» y del cálculo de las tasas de cumplimiento.
Por qué es importante
Base para calcular el estado de incumplimiento del SLA.
Dónde obtenerlo
Tabla «task_sla» de ServiceNow vinculada al problema
Ejemplos
2023-12-31T17:00:00Z
|
|||
|
Número de solicitud de cambio
ChangeRequestNumber
|
Identificador de la solicitud de cambio iniciada para corregir el problema. | ||
|
Descripción
Vincula el registro de problema con un registro de gestión de cambios (RFC). Esta conexión es esencial para que el Dashboard de eficiencia de transición de solicitudes de cambio mida la velocidad de la transferencia entre el diagnóstico del problema y la ejecución del cambio en la infraestructura.
Por qué es importante
Realiza un seguimiento de la transición de la gestión de problemas a la gestión de cambios.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «rfc»
Ejemplos
CHG003001CHG004552
|
|||
|
Resultado del PIR
PostImplementationReviewResult
|
Resultado o estado de finalización de la Post-Implementation Review. | ||
|
Descripción
Almacena el resultado o estado del PIR, por ejemplo, Completed, Not Required o Pending. Este atributo es necesario para el Dashboard «Cumplimiento de la Post-Implementation Review» y garantiza que los problemas importantes se revisen.
Por qué es importante
Métrica de control de calidad que garantiza el aprendizaje a partir de incidentes importantes.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «pir_state» o campo personalizado similar
Ejemplos
CompletadoExentoPendiente
|
|||
|
Servicio empresarial
BusinessService
|
Servicio empresarial de alto nivel afectado por el problema. | ||
|
Descripción
Representa el servicio orientado al negocio, por ejemplo, «Payroll Service» o «Customer Portal», en lugar del componente técnico. Proporciona una perspectiva centrada en el negocio para los informes dirigidos a las partes interesadas.
Por qué es importante
Conecta los problemas técnicos con las cadenas de valor del negocio.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «business_service»
Ejemplos
Banca en líneaCorreo electrónico interno
|
|||
|
Solución alternativa publicada
WorkaroundPublished
|
Indica si se ha documentado y compartido una solución alternativa. | ||
|
Descripción
Indicador booleano o de estado que señala si se ha identificado una corrección temporal y se ha publicado en la base de conocimientos o en la base de datos de errores conocidos. Permite utilizar el Dashboard de rendimiento de publicación de soluciones alternativas.
Por qué es importante
Esencial para medir la rapidez con la que se mitiga el impacto empresarial antes de aplicar una corrección definitiva.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «work_around» (si contiene texto) o estado específico
Ejemplos
truefalse
|
|||
|
Tiempo de elaboración de la solución
SolutionDraftingTime
|
Tiempo transcurrido entre la identificación de la causa raíz y la propuesta de una solución. | ||
|
Descripción
Registra la duración de la fase de diseño en la que se desarrolla una solución después de conocer la causa. Esto respalda el Dashboard «Elaboración de la solución y aplicación de la corrección».
Por qué es importante
Aísla el rendimiento de la fase de «diseño de la corrección».
Dónde obtenerlo
Calculado: marca de tiempo de «Proposed Solution Drafted» menos «Root Cause Identified»
Ejemplos
2 días4 horas
|
|||
Actividades de la gestión de problemas
| Actividad | Descripción | ||
|---|---|---|---|
|
Asignado a un grupo de soporte
|
Enrutamiento del registro de problema a un equipo técnico específico para su investigación. Esta actividad realiza un seguimiento del flujo de responsabilidad y es fundamental para analizar las transferencias. | ||
|
Por qué es importante
Esencial para que el Dashboard de análisis de reasignaciones de grupos de soporte identifique los efectos de ping-pong y los cuellos de botella entre equipos.
Dónde obtenerlo
Tabla «sys_audit» o «sys_history_line» de ServiceNow, que registra los cambios en el campo «assignment_group».
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Causa raíz identificada
|
Momento en que se completan los códigos de «Root Cause» o el estado cambia a «Fix in Progress». Representa el diagnóstico satisfactorio del problema. | ||
|
Por qué es importante
Calcula el tiempo medio hasta identificar la causa raíz y permite utilizar el Dashboard de tiempo de ciclo de la investigación de causas raíz. Es un hito importante del proceso.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, que registra los cambios en el campo de categoría «root_cause» o la transición al estado «Fix in Progress».
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Corrección permanente aplicada
|
Momento en que el problema se marca como resuelto, normalmente tras el cierre de la solicitud de cambio asociada. Indica que el trabajo técnico ha finalizado. | ||
|
Por qué es importante
Determina el final del ciclo de corrección activa. Se utiliza para calcular el tiempo total de resolución con respecto al SLA.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, transición del campo «state» a «Resolved» (el valor 106 es habitual).
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Investigación iniciada
|
Transición del estado del registro de problema de «New» a «Assess» o «Root Cause Analysis». Indica que un analista ha comenzado a trabajar activamente en el problema. | ||
|
Por qué es importante
Marca el final del tiempo de espera inicial en la cola y el inicio de la fase de investigación activa, lo que permite analizar los estados pendientes.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, que registra los cambios en el campo «state» (por ejemplo, el valor cambia a 102 o 103 según la configuración).
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Registro de problema cerrado
|
Evento final del ciclo de vida en el que el registro pasa a estar inactivo. No se espera ningún trabajo adicional. | ||
|
Por qué es importante
Punto final definitivo de la instancia del proceso. Es necesario para calcular el tiempo total de ciclo.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «closed_at» o transición del campo «state» a «Closed».
Recopilar
Se registra cuando se ejecuta la transacción Close Problem
Tipo de evento
explicit
|
|||
|
Registro de problema creado
|
Creación inicial de un registro de problema en el sistema ServiceNow. Esto marca el inicio del ciclo de vida de la gestión de problemas y establece la marca de tiempo de referencia para las métricas de antigüedad. | ||
|
Por qué es importante
Establece la hora de inicio de todos los cálculos del tiempo de ciclo y las mediciones de los SLA. Es el punto de referencia principal para identificar el volumen de investigaciones de problemas entrantes.
Dónde obtenerlo
Tabla «problem» de ServiceNow, campo «sys_created_on».
Recopilar
Se registra cuando se ejecuta la transacción New Record
Tipo de evento
explicit
|
|||
|
Solicitud de cambio iniciada
|
Asociación de una solicitud de cambio (RFC) con el registro de problema. Esto indica la transferencia de la gestión de problemas a la gestión de cambios para su implementación. | ||
|
Por qué es importante
Esencial para el Dashboard de eficiencia de transición de solicitudes de cambio. Identifica los retrasos entre la identificación de una corrección y el inicio del proceso de cambio.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, que registra la cumplimentación del campo de referencia «rfc» en la tabla «problem».
Recopilar
Se registra cuando se ejecuta la transacción Create Normal Change
Tipo de evento
explicit
|
|||
|
Solución alternativa identificada
|
Introducción de texto en el campo «Workaround» del registro de problema. Captura el momento en que el analista documenta una solución temporal. | ||
|
Por qué es importante
Permite al Dashboard de rendimiento de publicación de soluciones alternativas establecer cuándo se conoció por primera vez la solución técnica.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow donde «fieldname» es «workaround».
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Borrador de solución propuesto
|
Introducción de datos en los campos «Fix Notes» o «Resolution Code». Indica que el analista ha pasado de comprender la causa a diseñar la corrección permanente. | ||
|
Por qué es importante
Permite al Dashboard de elaboración de soluciones y aplicación de correcciones aislar la duración de la fase de diseño.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, que registra las actualizaciones del campo «fix_notes».
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Estado cambiado a Fix in Progress
|
El registro pasa a un estado que indica que se está desarrollando o implementando una corrección, a menudo a la espera de la gestión de cambios. | ||
|
Por qué es importante
Diferencia el tiempo de investigación activa del tiempo de espera del cambio y mejora el análisis de cuellos de botella.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, transición del campo «state» a «Fix in Progress» (el valor 104 es habitual).
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Evaluación rechazada
|
El registro de problema vuelve a un estado anterior o se cancela durante la fase de evaluación porque no era un problema válido. | ||
|
Por qué es importante
Identifica el desperdicio en el proceso cuando los incidentes se convierten incorrectamente en problemas.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow, transición del campo «state» a «Closed/Cancelled» o «New» desde «Assess».
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Resolución verificada
|
Paso de validación en el que se confirma que la resolución es eficaz. Puede corresponder a un estado específico o a una casilla de verificación, según el grado de madurez del proceso. | ||
|
Por qué es importante
Garantiza el control de calidad antes del cierre. Omitir este paso permite analizar las desviaciones del proceso.
Dónde obtenerlo
Tabla «sys_audit» de ServiceNow. Puede ser un cambio de estado («Resolved» → «Closed») o un campo específico «u_resolution_verified», si está configurado.
Recopilar
Comparar el campo de estado antes y después
Tipo de evento
inferred
|
|||
|
Revisión posterior a la implementación completada
|
Finalización de la tarea PIR o activación de un indicador PIR. Confirma que se realizó un análisis retrospectivo de los problemas graves. | ||
|
Por qué es importante
Permite directamente utilizar el Dashboard de cumplimiento de la revisión posterior a la implementación. La ausencia de esta actividad en problemas de alta prioridad indica un incumplimiento.
Dónde obtenerlo
Cierre de la tabla «problem_task» de ServiceNow (type=PIR) o cambio del campo «pir_state» de la tabla «problem».
Recopilar
Derivar comparando el campo X con el campo Y
Tipo de evento
inferred
|
|||
|
Solución alternativa publicada
|
Ejecución de la acción «Communicate Workaround», que envía la solución alternativa a los incidentes relacionados o crea un artículo de error conocido. Esto es distinto de introducir simplemente la solución alternativa. | ||
|
Por qué es importante
Es fundamental para medir la velocidad de difusión del conocimiento. Los retrasos en este punto afectan directamente al volumen de incidentes recurrentes.
Dónde obtenerlo
Tabla «sys_journal_field» de ServiceNow o registros específicos de UI Action; también puede inferirse si se crea un registro «kb_knowledge» de tipo «Known Error».
Recopilar
Se registra cuando se ejecuta la transacción Communicate Workaround
Tipo de evento
explicit
|
|||
Guías de extracción
¿Listo para comenzar?
Descargue la plantilla completa y empiece hoy mismo a transformar sus datos de gestión de problemas en información útil para la toma de decisiones. Nuestro equipo está aquí para acompañarle en cada etapa de su recorrido con Process Mining.
Optimice la gestión de problemas para resolverlos más rápido
Reduzca un 30 % el tiempo de su ciclo de investigación con Process Mining
No necesita tarjeta de crédito. Configuración en minutos.