Su Plantilla de Datos para la Gestión de Problemas
Su Plantilla de Datos para la Gestión de Problemas
- Atributos recomendados para el análisis de causa raíz
- Hitos y actividades clave del proceso
- Guía de extracción paso a paso de ServiceNow
Atributos de Gestión de Problemas
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
Activity
|
El evento o acción específica realizada en el registro del problema. | ||
|
Descripción
Representa los distintos pasos o cambios de estado que ocurren durante el ciclo de vida de un registro de problema. Los ejemplos incluyen 'Registro de Problema Creado', 'Causa Raíz Identificada' o 'Asignado a Grupo de Soporte'. Este atributo es crucial para construir el mapa de procesos y visualizar la secuencia de eventos.
Por qué es importante
Define los nodos en el mapa de procesos, permitiendo la visualización del flujo de trabajo y las variantes del proceso.
Dónde obtener
Derivado de las tablas 'sys_audit', 'sys_history_line' o de cambios de estado en la tabla 'problem'
Ejemplos
Registro de Problema CreadoAnálisis CompletadoEstado Cambiado a Cerrado
|
|||
|
Registro de Problema
ProblemNumber
|
El identificador único para el registro del problema. | ||
|
Descripción
La clave alfanumérica única asignada a un registro de problema específico dentro de ServiceNow (ej., PRB000123). Este identificador sirve como el hilo conductor central que une todas las actividades del proceso, desde el registro inicial hasta el análisis de la causa raíz y el cierre final. En el análisis de Process Mining, este atributo funciona como el ID de Caso, permitiendo la reconstrucción del 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 gráfico de procesos.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'number'.
Ejemplos
PRB004512PRB009823PRB001122
|
|||
|
Timestamp del Evento
EventTime
|
La fecha y hora exactas en que ocurrió una actividad. | ||
|
Descripción
Registra la marca de tiempo específica cuando un cambio o acción fue registrado en el sistema. Este punto de datos es fundamental para ordenar las actividades cronológicamente y calcular métricas de duración como tiempos de ciclo y tiempos de espera entre los pasos del proceso.
Por qué es importante
Esencial para ordenar eventos y calcular todos los KPIs basados en el tiempo.
Dónde obtener
Campo 'sys_created_on' de ServiceNow en tablas de auditoría/historial
Ejemplos
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
Source System
SourceSystem
|
El nombre del sistema donde se originaron los datos. | ||
|
Descripción
Identifica la instancia o entorno específico de ServiceNow desde donde se extrajeron los datos de gestión de problemas. Esto es particularmente útil en entornos multisistema para rastrear el linaje de datos y manejar matices específicos del sistema en el análisis.
Por qué es importante
Proporciona contexto para el origen de los datos, especialmente al fusionar datos de múltiples herramientas ITSM.
Dónde obtener
Codificado directamente durante la extracción (por ejemplo, 'ServiceNow Production')
Ejemplos
ServiceNow ProdServiceNow EMEA
|
|||
|
Última actualización de datos
LastDataUpdate
|
La marca de tiempo cuando los datos fueron extraídos o actualizados por última vez. | ||
|
Descripción
Indica la actualidad del conjunto de datos utilizado para el análisis. Ayuda a los analistas a comprender si están viendo datos en tiempo real o una instantánea histórica, lo cual es crítico para interpretar correctamente los estados de los casos abiertos.
Por qué es importante
Asegura que los usuarios sepan cuán actualizados están los datos para una elaboración de informes operativos precisos.
Dónde obtener
Hora del sistema en el momento de la ejecución de ETL
Ejemplos
2023-11-01T12:00:00Z
|
|||
|
Categoría de Causa Raíz
RootCauseCategory
|
La clasificación de la causa raíz identificada. | ||
|
Descripción
Categoriza la razón subyacente del problema, como Error de Software, Error Humano o Fallo de Hardware. Este atributo impulsa el dashboard de 'Precisión de la Categorización de la Causa Raíz' y ayuda a identificar patrones de fallo sistémicos.
Por qué es importante
Permite el análisis de patrones de fallos para impulsar mejoras estratégicas.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'rca_category' o 'u_root_cause_category'.
Ejemplos
Defecto de Software`Error de Configuración`Problema de Proveedor
|
|||
|
Conteo de Incidentes Relacionados
RelatedIncidentCount
|
El número de incidentes vinculados a este registro de problema. | ||
|
Descripción
Cuantifica el impacto del problema al contar el número de incidentes asociados. Los recuentos elevados en este campo, particularmente para los Errores Conocidos, alimentan el dashboard 'Errores Conocidos y Recurrencia de Incidentes'.
Por qué es importante
Mide la magnitud del impacto en el usuario causado por el problema.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'related_incidents' (el nombre del campo varía) o conteo de registros vinculados.
Ejemplos
1501200
|
|||
|
Estado del Problema
ProblemState
|
El estado del ciclo de vida del registro del problema. | ||
|
Descripción
Refleja la etapa actual del registro del problema, como Abierto, Análisis de Causa Raíz, Solución en Progreso o Cerrado. Este es un factor principal para filtrar y comprender la composición del backlog en el 'Análisis de Antigüedad de Registros de Problemas Antiguos'.
Por qué es importante
El indicador de estado principal utilizado para filtrar casos abiertos versus cerrados.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'state'.
Ejemplos
NuevoEvaluarAnálisis de Causa RaízResuelto
|
|||
|
Grupo de Soporte
AssignmentGroup
|
El equipo técnico responsable de la resolución del problema. | ||
|
Descripción
Designa el grupo de soporte o equipo específico actualmente asignado al problema. Este atributo es vital para el dashboard de 'Análisis de Reasignación de Grupos de Soporte' para rastrear los traspasos entre equipos e identificar silos organizacionales.
Por qué es importante
Crucial para identificar cuellos de botella entre departamentos y analizar la eficiencia de traspaso.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'assignment_group'.
Ejemplos
Operaciones de RedAdministradores de Base de DatosMesa de Ayuda
|
|||
|
Prioridad
Priority
|
El nivel de prioridad asignado al registro del problema. | ||
|
Descripción
Indica la importancia y urgencia del problema, típicamente calculado a partir del impacto y la urgencia. Este atributo permite la segmentación del análisis por criticidad, apoyando el dashboard de 'Incumplimiento de SLA y Monitoreo de Prioridad'.
Por qué es importante
Permite la segmentación del rendimiento del proceso por criticidad del negocio.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'priority'.
Ejemplos
1 - Crítico2 - Alta3 - Moderada
|
|||
|
Recuento de Reasignaciones
ReassignmentCount
|
El número de veces que el problema fue reasignado entre grupos. | ||
|
Descripción
Un contador que rastrea la frecuencia con la que ha cambiado el grupo de asignación. Esta es la fuente directa para el KPI de 'Recuento de Reasignaciones de Registros de Problemas' y ayuda a identificar efectos de 'ping-pong' donde los tickets rebotan entre equipos.
Por qué es importante
Indicador directo de fricción del proceso y falta de una propiedad clara.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'reassignment_count'.
Ejemplos
0312
|
|||
|
Usuario Asignado
AssignedTo
|
El individuo específico asignado para trabajar en el problema. | ||
|
Descripción
Identifica al usuario actualmente responsable 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 obtener
Tabla 'problem' de ServiceNow, campo 'assigned_to'.
Ejemplos
Alice SmithBob JonesAdministrador del Sistema
|
|||
|
Duración de RCA
RootCauseAnalysisDuration
|
Tiempo transcurrido desde la creación del problema hasta la identificación de la causa raíz. | ||
|
Descripción
Una duración calculada que mide la eficiencia de la fase de investigación. Esto apoya directamente el KPI de 'Tiempo Medio hasta la Causa Raíz' y ayuda a identificar brechas de habilidades técnicas o problemas de complejidad.
Por qué es importante
Métrica clave de eficiencia para la fase de investigación.
Dónde obtener
Calculado: Marca de tiempo de la actividad 'Causa Raíz Identificada' menos la hora de 'Registro de Problema Creado'
Ejemplos
3 días 4 horas12 horas
|
|||
|
Duración Pendiente
PendingDuration
|
Tiempo total que el problema pasó en estado suspendido o pendiente. | ||
|
Descripción
Agrupa el tiempo dedicado en estados como 'Pendiente de Proveedor' o 'En Espera'. Esta métrica se utiliza para el 'Análisis de Estado Pendiente y Tiempo de Espera' para separar el tiempo de procesamiento interno de los retrasos externos.
Por qué es importante
Diferencia entre la ineficiencia del equipo y las dependencias externas.
Dónde obtener
Calculado: Suma de la duración de los intervalos donde el Estado = Pendiente/En Espera
Ejemplos
5 días0 minutos
|
|||
|
Elemento de Configuración
ConfigurationItem
|
El activo o servicio específico afectado por el problema. | ||
|
Descripción
Identifica el Elemento de Configuración (CI) vinculado al registro de problema. Analizar esto ayuda a correlacionar problemas con hardware, software o servicios específicos, apoyando el dashboard de 'Precisión de la Categorización de la Causa Raíz'.
Por qué es importante
Vincula problemas de proceso a activos físicos o lógicos específicos.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'cmdb_ci'.
Ejemplos
Servidor SAP ERP 01Servicio de Correo Electrónico ExchangeOracle DB Prod
|
|||
|
Es Error Conocido
IsKnownError
|
Indicador de si el problema se clasifica como un Error Conocido. | ||
|
Descripción
Identifica si el registro de problema se ha convertido o marcado como un Error Conocido. Esto es esencial para el análisis de 'Error Conocido y Recurrencia de Incidentes' para ver si el proceso de gestión del conocimiento es efectivo.
Por qué es importante
Distingue entre investigaciones activas y defectos aceptados con soluciones provisionales.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'known_error'.
Ejemplos
truefalse
|
|||
|
Fecha de Vencimiento de SLA
SlaDueDate
|
La fecha/hora objetivo para la resolución del problema según el SLA. | ||
|
Descripción
La marca de tiempo que indica cuándo debe resolverse el problema para cumplir con los acuerdos de nivel de servicio. Esta es la línea de base para el dashboard 'Monitoreo de Incumplimientos de SLA y Prioridad' y para calcular las tasas de cumplimiento.
Por qué es importante
Línea base para calcular el estado de incumplimiento de SLA.
Dónde obtener
Tabla 'task_sla' de ServiceNow vinculada al problema
Ejemplos
2023-12-31T17:00:00Z
|
|||
|
Número de Solicitud de Cambio
ChangeRequestNumber
|
El identificador de la solicitud de cambio iniciada para solucionar el problema. | ||
|
Descripción
Vincula el registro de problema a un registro de Gestión de Cambios (RFC). Esta conexión es vital para el dashboard de 'Eficiencia de Transición de Solicitud de Cambio' para medir la velocidad de traspaso entre el diagnóstico del problema y la ejecución del cambio de infraestructura.
Por qué es importante
Rastrea la transición de la gestión de problemas a la gestión de cambios.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'rfc'.
Ejemplos
CHG003001CHG004552
|
|||
|
Resultado PIR
PostImplementationReviewResult
|
El resultado o estado de finalización de la Revisión Post-Implementación. | ||
|
Descripción
Almacena el resultado o estado del PIR (ej., Completado, No Requerido, Pendiente). Este atributo es necesario para el dashboard 'Cumplimiento de Revisión Post-Implementación' para asegurar que los problemas mayores sean revisados.
Por qué es importante
Métrica de control de calidad que asegura el aprendizaje de incidentes mayores.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'pir_state' o campo personalizado similar.
Ejemplos
CompletadoEximidoPendiente
|
|||
|
Servicio de Negocio
BusinessService
|
El servicio empresarial de alto nivel impactado por el problema. | ||
|
Descripción
Representa el servicio orientado al negocio (por ejemplo, 'Servicio de Nómina', 'Portal del Cliente') en lugar del componente técnico. Esto proporciona una vista centrada en el negocio para informar a las partes interesadas.
Por qué es importante
Conecta problemas técnicos con los flujos de valor de negocio.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'business_service'.
Ejemplos
Banca en LíneaCorreo Electrónico Interno
|
|||
|
Solución Provisional Publicada
WorkaroundPublished
|
Indica si se ha documentado y compartido una solución provisional. | ||
|
Descripción
Una bandera booleana o de estado que indica si se ha identificado y publicado una solución provisional en la Base de Conocimiento o en la Base de Datos de Errores Conocidos. Esto apoya el dashboard de 'Rendimiento de Publicación de Soluciones Provisionales'.
Por qué es importante
Crítico para medir con qué rapidez se mitiga el impacto comercial antes de una solución final.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'work_around' (presencia de texto) o estado específico.
Ejemplos
truefalse
|
|||
|
Tiempo de Redacción de Soluciones
SolutionDraftingTime
|
Tiempo entre la identificación de la causa raíz y la propuesta de una solución. | ||
|
Descripción
Rastrea la duración de la fase de diseño donde se desarrolla una solución una vez que se conoce la causa. Esto soporta el dashboard 'Redacción de Soluciones y Aplicación de Correcciones'.
Por qué es importante
Aísla el rendimiento de la fase de 'diseño de la solución'.
Dónde obtener
Calculado: Marca de tiempo de 'Solución Propuesta Redactada' menos 'Causa Raíz Identificada'
Ejemplos
2 días4 horas
|
|||
Actividades de Gestión de Problemas
| Actividad | Descripción | ||
|---|---|---|---|
|
Asignado a Grupo de Soporte
|
El enrutamiento del registro de problema a un equipo técnico específico para su investigación. Esta actividad rastrea el flujo de propiedad y es crítica para analizar las transferencias. | ||
|
Por qué es importante
Esencial para el dashboard de Análisis de Reasignación de Grupos de Soporte para identificar efectos de ping-pong y cuellos de botella entre equipos.
Dónde obtener
Tabla 'sys_audit' o 'sys_history_line' de ServiceNow rastreando cambios en el campo 'assignment_group'.
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Causa Raíz Identificada
|
El punto donde se completan los códigos de 'Causa Raíz' o el estado cambia a 'Solución en Progreso'. Esto representa el diagnóstico exitoso del problema. | ||
|
Por qué es importante
Calcula el Tiempo Medio hasta la Causa Raíz y apoya el dashboard de Tiempo de Ciclo de Investigación de Causa Raíz. Es un hito importante del proceso.
Dónde obtener
Tabla 'sys_audit' de ServiceNow rastreando cambios en el campo de categoría 'root_cause' o transición al estado 'Fix in Progress'.
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Investigación Iniciada
|
La transición del estado del registro de problema de 'New' (Nuevo) a 'Assess' (Evaluar) o 'Root Cause Analysis' (Análisis de Causa Raíz). Significa que un analista ha comenzado a trabajar activamente en el problema. | ||
|
Por qué es importante
Marca el final del tiempo inicial de espera en cola y el inicio de la fase de investigación activa, apoyando el análisis de Estado Pendiente.
Dónde obtener
Tabla 'sys_audit' de ServiceNow rastreando cambios en el campo 'state' (ej., valor que cambia a 102 o 103 según la configuración).
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Registro de Problema Cerrado
|
El evento final del ciclo de vida donde el registro se vuelve inactivo. No se espera trabajo adicional. | ||
|
Por qué es importante
El punto final definitivo para la instancia del proceso. Requerido para calcular el tiempo total del ciclo.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'closed_at' o transición de 'state' a 'Closed'.
Capturar
Registrado cuando se ejecutó la transacción 'Cerrar Problema'
Tipo de evento
explicit
|
|||
|
Registro de Problema Creado
|
La 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 para todos los cálculos de tiempo de ciclo y mediciones de SLA. Es el ancla principal para identificar el volumen de investigaciones de problemas entrantes.
Dónde obtener
Tabla 'problem' de ServiceNow, campo 'sys_created_on'.
Capturar
Registrado cuando se ejecutó la transacción 'Nuevo Registro'
Tipo de evento
explicit
|
|||
|
Solicitud de Cambio Iniciada
|
La asociación de una Solicitud de Cambio (RFC) al Registro de Problema. Esto significa la transferencia de la Gestión de Problemas a la Gestión de Cambios para su implementación. | ||
|
Por qué es importante
Vital para el dashboard de Eficiencia de Transición de Solicitudes de Cambio. Identifica retrasos entre la búsqueda de una solución y el inicio del proceso de cambio.
Dónde obtener
Tabla 'sys_audit' de ServiceNow rastreando la población del campo de referencia 'rfc' en la tabla 'problem'.
Capturar
Registrado cuando se ejecutó la transacción 'Crear Cambio Normal'
Tipo de evento
explicit
|
|||
|
Solución Permanente Aplicada
|
El momento en que el problema se marca como Resuelto, a menudo desencadenado por el cierre de la Solicitud de Cambio asociada. Esto indica que el trabajo técnico está completo. | ||
|
Por qué es importante
Determina el final del ciclo de solución activo. Se utiliza para calcular el tiempo total de resolución en relación con el SLA.
Dónde obtener
Tabla 'sys_audit' de ServiceNow, transición del campo 'state' a 'Resolved' (valor 106 típico).
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Solución Provisional Identificada
|
El acto de introducir texto en el campo 'Workaround' (solución provisional) del registro de problema. Esto captura el momento en que un analista documenta una solución temporal. | ||
|
Por qué es importante
Soporta el dashboard de Rendimiento de Publicación de Soluciones Provisionales al establecer cuándo se conoció por primera vez la solución técnica.
Dónde obtener
Tabla 'sys_audit' de ServiceNow donde 'fieldname' es 'workaround'.
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Estado Cambiado a Solución en Progreso
|
El registro transita a un estado que indica que se está construyendo o desplegando una solución (a menudo esperando la Gestión de Cambios). | ||
|
Por qué es importante
Diferencia el tiempo de investigación activa del tiempo de 'espera de cambio', refinando el análisis de cuellos de botella.
Dónde obtener
Tabla 'sys_audit' de ServiceNow, transición del campo 'state' a 'Fix in Progress' (valor 104 típico).
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Evaluación Rechazada
|
El registro del problema se devuelve 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 donde los incidentes se promueven incorrectamente a problemas.
Dónde obtener
Tabla 'sys_audit' de ServiceNow, transición del campo 'state' a 'Closed/Cancelled' o 'New' desde 'Assess'.
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Resolución Verificada
|
Un paso de validación donde se confirma que la resolución es efectiva. Esto puede ser un estado específico o una casilla de verificación dependiendo de la madurez del proceso. | ||
|
Por qué es importante
Asegura el control de calidad antes del cierre. Omitir este paso permite el análisis de Desviación del Proceso.
Dónde obtener
Tabla 'sys_audit' de ServiceNow. Puede ser un cambio de estado (Resolved -> Closed) o un campo específico 'u_resolution_verified' si está configurado.
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Revisión Post-Implementación Completada
|
La finalización de la tarea PIR o el establecimiento de un indicador PIR. Esto confirma que se realizó un análisis retrospectivo para problemas mayores. | ||
|
Por qué es importante
Apoya directamente el dashboard de Cumplimiento de Revisión Post-Implementación. La ausencia de esta actividad en problemas de alta prioridad indica un fallo en el cumplimiento.
Dónde obtener
Cierre de la tabla 'problem_task' de ServiceNow (tipo=PIR), o cambio de campo 'pir_state' en la tabla 'problem'.
Capturar
Derivar de la comparación del
Tipo de evento
inferred
|
|||
|
Solución Propuesta Redactada
|
La entrada de datos en los campos 'Fix Notes' (Notas de Corrección) o 'Resolution Code' (Código de Resolución). Indica que el analista ha pasado de comprender la causa a diseñar la solución permanente. | ||
|
Por qué es importante
Soporta el dashboard de Redacción de Soluciones y Aplicación de Correcciones al aislar la duración de la fase de diseño.
Dónde obtener
Tabla 'sys_audit' de ServiceNow rastreando actualizaciones en el campo 'fix_notes'.
Capturar
Compare el campo de estado antes/después
Tipo de evento
inferred
|
|||
|
Solución Provisional Publicada
|
La ejecución de la acción 'Communicate Workaround' (Comunicar Solución Provisional), que envía la solución provisional a incidentes relacionados o crea un artículo de Error Conocido. Esto es distinto de simplemente escribir la solución provisional. | ||
|
Por qué es importante
Crítico para medir la velocidad del intercambio de conocimientos. Los retrasos aquí impactan directamente el volumen de incidentes recurrentes.
Dónde obtener
Campo 'sys_journal_field' o logs de acciones de UI específicas de ServiceNow; también se puede inferir si se crea un registro 'kb_knowledge' de tipo 'Known Error'.
Capturar
Registrado cuando se ejecutó la transacción 'Comunicar Solución Provisional'
Tipo de evento
explicit
|
|||