Su Template de datos de Gestión de problemas
Su Template de datos de Gestión de problemas
- Campos de datos esenciales para el análisis de causas raíz
- Hitos de proceso estandarizados para el seguimiento
- Instrucciones específicas para extraer datos de BMC Helix ITSM
Atributos de Gestión de problemas
| Nombre | Descripción | ||
|---|---|---|---|
|
Actividad
Activity
|
La Task específica o el cambio de estado que se produjo. | ||
|
Descripción
Este atributo representa el paso específico realizado durante el ciclo de vida de la gestión de problemas, como 'Registro del problema', 'Causa raíz identificada' o 'Base de datos de soluciones actualizada'. En BMC Helix, suele derivarse del historial de estados, los registros de auditoría o las marcas de tiempo de transacciones específicas del módulo Problem Investigation. Este atributo es fundamental para descubrir el proceso. Al analizar la secuencia de actividades, la herramienta de Process Mining construye el mapa del proceso y muestra el flujo de trabajo real en comparación con el proceso diseñado. También pone de manifiesto los ciclos, el retrabajo y las desviaciones del procedimiento operativo estándar. Los nombres precisos de las actividades son esenciales para entender qué ocurrió realmente durante el ciclo de vida. Estos datos permiten medir el tiempo entre pasos específicos, por ejemplo, cuánto transcurrió entre la identificación de una causa raíz y el inicio de una solicitud de cambio.
Por qué es importante
Define los nodos del mapa del proceso y permite visualizar el flujo de trabajo.
Dónde obtenerlo
Se deriva del historial de estados de PBM:Problem Investigation o de PBM:AuditLogSystem
Ejemplos
Registro del problemaAsignado a un grupo de soporteInicio de la investigaciónCausa raíz identificada
|
|||
|
Hora del evento
EventTime
|
La marca de tiempo en que se produjo la actividad específica. | ||
|
Descripción
Este atributo registra la fecha y hora exactas en que tuvo lugar una actividad. En BMC Helix ITSM, corresponde a campos como 'Submit Date' o 'Last Modified Date', o a marcas de tiempo específicas registradas en las tablas de historial para los cambios de estado. En el análisis, este atributo permite ordenar cronológicamente los eventos y calcular duraciones. Así se pueden medir los tiempos de ciclo entre dos puntos cualesquiera del proceso, como el 'Tiempo de investigación' o el 'Tiempo hasta la publicación de la solución temporal'. Las marcas de tiempo precisas son fundamentales para identificar cuellos de botella. Al calcular el tiempo entre eventos consecutivos, las personas analistas pueden determinar exactamente dónde se producen las demoras, ya sea durante la asignación inicial o en la fase de revisión final.
Por qué es importante
Permite calcular todos los KPI basados en la duración y ordenar los eventos.
Dónde obtenerlo
Tablas de historial o registros de auditoría asociados a PBM:Problem Investigation
Ejemplos
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
Registro del problema
ProblemRecord
|
Identificador único del caso de investigación del problema. | ||
|
Descripción
Este atributo funciona como identificador central del caso en el proceso de gestión de problemas. En BMC Helix ITSM, suele corresponder al campo 'Problem ID' del formulario PBM:Problem Investigation (por ejemplo, PBI00000012345). Vincula todas las actividades relacionadas, desde el registro inicial del problema hasta el cierre definitivo y la revisión posterior a la implementación. En el análisis de Process Mining, este atributo permite agrupar eventos individuales en una sola instancia del proceso. Así, las personas analistas pueden visualizar el recorrido completo de una investigación específica. Sin este identificador, sería imposible relacionar la secuencia de acciones realizadas por distintos grupos de soporte y coordinadores. Este campo funciona como clave principal del Registro de eventos y es esencial para todas las agregaciones por caso, como calcular el tiempo de ciclo total por problema o contar los problemas de cada nivel de prioridad.
Por qué es importante
Es la clave fundamental para construir la vista del proceso y seguir el ciclo de vida de problemas específicos.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Problem ID'
Ejemplos
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Sistema de origen
SourceSystem
|
El sistema del que proceden los datos. | ||
|
Descripción
Este atributo identifica el sistema de software del que se extrajeron los datos del proceso, en este caso, 'BMC Helix ITSM'. Es especialmente importante en entornos con varios sistemas, donde Process Mining puede combinar datos de distintas herramientas de ITSM, desarrollo o proveedores externos. En el análisis, este campo funciona como una etiqueta de metadatos que permite validar el origen del registro. Si la vista del proceso combina datos de BMC Helix para la gestión de problemas con los de otro sistema de desarrollo de software, como Jira, este atributo ayuda a segmentar el análisis según la herramienta de origen. También facilita la resolución de problemas técnicos. Si surgen problemas de calidad de los datos, conocer el sistema de origen permite que el equipo de ingeniería de datos rastree el problema hasta la rutina de extracción o la base de datos de origen correspondiente.
Por qué es importante
Aporta trazabilidad y contexto, especialmente en las vistas de procesos que combinan varios sistemas.
Dónde obtenerlo
Se define durante el proceso de extracción
Ejemplos
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
Última actualización de los datos
LastDataUpdate
|
La marca de tiempo de la extracción o de la última actualización de los datos. | ||
|
Descripción
Este atributo indica cuándo se cargaron los datos por última vez en la aplicación de Process Mining. Permite que las personas analistas sepan qué tan actualizados están los datos que consultan. Por lo general, lo genera el script de extracción o la herramienta de canalización de datos. En el análisis, ayuda a evitar decisiones basadas en datos desactualizados. Por ejemplo, si una persona responsable consulta los 'Registros de problemas abiertos', saber si los datos se actualizaron hace una hora o hace una semana cambia considerablemente la interpretación de la carga de trabajo actual. También se utiliza para las cargas incrementales de datos. Al registrar la hora de la última actualización, el proceso ETL puede obtener solo los registros que cambiaron desde la extracción anterior, lo que optimiza el rendimiento y reduce la carga del sistema.
Por qué es importante
Permite mantener los datos actualizados y facilita las estrategias de carga incremental.
Dónde obtenerlo
Hora del sistema en el momento de la extracción
Ejemplos
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
¿Se incumplió el SLA?
IsSLABreached
|
Indicador que señala si la resolución del problema superó el tiempo permitido. | ||
|
Descripción
Este atributo booleano indica si el registro del problema incumplió el acuerdo de nivel de servicio. Se calcula comparando la marca de tiempo de «Resolución verificada» con la «Fecha límite del SLA», o se extrae directamente del estado de SLM. Este atributo es fundamental para el Dashboard «Cumplimiento del SLA y tendencias de incumplimiento». Permite segmentar el proceso de forma sencilla en casos conformes y no conformes. Así es más fácil identificar las características de los procesos que fallan (por ejemplo, «¿Los casos que incumplen el SLA siempre involucran al grupo de soporte X?»). También sirve como filtro principal para analizar la causa raíz de los fallos del proceso. Los analistas pueden filtrar por «IsSLABreached = True» y examinar el mapa del proceso para ver dónde se perdió tiempo, por ejemplo, en largas esperas por la aprobación de un proveedor.
Por qué es importante
Facilita los informes de cumplimiento y el análisis de fallos.
Dónde obtenerlo
Formulario SLM:Measurement o cálculo
Ejemplos
truefalse
|
|||
|
Cantidad de incidentes relacionados
RelatedIncidentCount
|
El número de incidentes vinculados a este registro de problema. | ||
|
Descripción
Este atributo cuantifica el impacto del problema al contar los incidentes asociados. En BMC Helix, suele corresponder al número de registros del formulario HPD:Help Desk relacionados con el registro PBM. Este atributo alimenta el KPI «Densidad de vínculos entre incidentes». Un valor alto indica que el problema tiene un gran impacto y genera una carga considerable para la mesa de ayuda. Al relacionarlo con la «Prioridad», se puede comprobar si los problemas que generan más incidentes reciben realmente un tratamiento crítico. También ayuda a priorizar el trabajo pendiente. Probablemente convenga priorizar un registro de problema con 500 incidentes vinculados frente a uno «Crítico» con un solo incidente, ya que resolver el primero liberará más capacidad de la mesa de ayuda.
Por qué es importante
Cuantifica el impacto operativo del problema y las dificultades que causa a los usuarios.
Dónde obtenerlo
Se calcula contando las filas relacionadas en HPD:Associations o HPD:Help Desk
Ejemplos
15120
|
|||
|
Categoría de la causa raíz
RootCauseCategory
|
La clasificación de la causa subyacente del problema. | ||
|
Descripción
Este atributo contiene la categoría seleccionada al identificar la causa raíz (por ejemplo, 'Error de software', 'Fallo de hardware' o 'Deficiencia del proceso'). En BMC Helix, suele seleccionarse en los menús 'Root Cause' o 'Generic Categorization'. Este atributo es esencial para la vista 'Eficacia y calidad de las soluciones'. Permite relacionar tipos específicos de causas raíz con las tasas de retrabajo o los tiempos prolongados de investigación. Por ejemplo, podría revelar que los problemas de 'Error de software' tardan sistemáticamente el doble en resolverse que los de 'Fallo de hardware'. También se utiliza para calcular la 'Tasa de clasificación de causas raíz'. Un porcentaje elevado de valores 'Desconocido' u 'Otro' en este campo sugiere que se necesita más formación técnica o que las opciones de clasificación deberían ser más detalladas.
Por qué es importante
Permite analizar las tendencias de los problemas sistémicos y facilita una gestión proactiva de los problemas.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campos de la pestaña 'Root Cause' o de clasificación
Ejemplos
Módulo de softwareInfraestructura de redError humano
|
|||
|
CI del servicio
ServiceCI
|
El servicio empresarial principal o el elemento de configuración afectado. | ||
|
Descripción
Este atributo identifica el elemento de configuración del servicio (CI) relacionado con el problema, como 'Servicio de correo electrónico', 'SAP ERP' o 'Red Wi-Fi'. En BMC Helix, suele corresponder al campo 'Service+' o a la relación con el CI principal. En el análisis, permite segmentar los registros de problemas por producto o servicio. Ayuda a la dirección de TI a entender qué servicios son más vulnerables y generan más investigaciones de problemas. Además, añade una dimensión de producto al Dashboard 'Volumen y prioridad de los casos'. Relacionar este atributo con el 'Tiempo de investigación' permite comprobar si ciertos servicios complejos, como un sistema bancario central, requieren por naturaleza investigaciones más largas que los servicios comunes, como la impresión.
Por qué es importante
Relaciona el rendimiento del proceso con productos o servicios específicos de la empresa.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'ServiceCI' o 'CI Name'
Ejemplos
Servicio de correo electrónicoSistema de nóminaVPN corporativa
|
|||
|
Coordinador de problemas
ProblemCoordinator
|
La persona asignada para coordinar la investigación. | ||
|
Descripción
Este atributo indica quién es la persona responsable del registro del problema. En BMC Helix ITSM, corresponde al campo 'Problem Coordinator'. Esta persona se encarga del ciclo de vida del problema, aunque delegue tareas en otras personas. Este atributo facilita el análisis del Dashboard 'Distribución de la carga de trabajo por grupo de soporte'. Ayuda a la dirección a identificar si algunas personas tienen demasiadas investigaciones asignadas mientras otras disponen de capacidad. También permite analizar el rendimiento individual e identificar necesidades de formación o un desempeño destacado. En Process Mining, este campo funciona como un atributo de recurso. Permite visualizar cómo se distribuye el trabajo entre las personas y puede revelar puntos únicos de fallo cuando un proceso depende demasiado de una persona experta.
Por qué es importante
Permite analizar los recursos y equilibrar la carga de trabajo a nivel individual.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Problem Coordinator'
Ejemplos
John DoeJane SmithAdministrador del sistema
|
|||
|
Fecha límite del SLA
SLADueDate
|
La fecha y hora límite para resolver el problema. | ||
|
Descripción
Este atributo contiene la fecha límite para resolver el problema, según el acuerdo de nivel de servicio. En BMC Helix, suele corresponder a «Fecha objetivo de resolución» o a la marca de tiempo calculada de un hito del SLA. Este atributo sirve de referencia para el Dashboard «Cumplimiento del SLA y tendencias de incumplimiento». Al comparar esta marca de tiempo con la de la actividad «Resolución verificada», el sistema calcula si se cumplió o se incumplió el SLA. Al visualizar esta fecha, los analistas pueden ver con cuánto margen trabaja el equipo. ¿Resuelve los problemas con días de anticipación o suele terminarlos apenas unos minutos antes de incumplir el SLA? Esta información permite planificar la capacidad.
Por qué es importante
Es el punto de referencia para calcular todas las métricas de cumplimiento y puntualidad.
Dónde obtenerlo
PBM: formulario de investigación de problemas, campo «Fecha objetivo de resolución»
Ejemplos
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Grupo de soporte
SupportGroup
|
El equipo técnico asignado actualmente a la investigación del problema. | ||
|
Descripción
Este atributo indica el grupo de soporte específico (por ejemplo, 'Administración de servidores' o 'Soporte de bases de datos') responsable del registro del problema en el momento del evento. En BMC Helix, corresponde al campo 'Assigned Group'. Este atributo es fundamental para los Dashboards 'Distribución de la carga de trabajo por grupo de soporte' y 'Análisis de reasignaciones entre grupos de soporte'. Permite que las personas analistas segmenten el mapa del proceso por equipo y vean qué grupos gestionan más casos y cuáles generan cuellos de botella durante la investigación. Analizar los traspasos entre grupos de soporte ayuda a detectar cambios repetidos de equipo, cuando un ticket pasa de un grupo a otro sin resolverse. Esto suele indicar que las responsabilidades no están claras o que la gestión del conocimiento en la organización es insuficiente.
Por qué es importante
Permite analizar la organización y detectar cuellos de botella a nivel de equipo.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Assigned Group'
Ejemplos
Mesa de ayuda, nivel 1Soporte administrativoAdministración de redes
|
|||
|
Motivo de la investigación
InvestigationDriver
|
La razón por la que se inició la investigación del problema. | ||
|
Descripción
Este atributo clasifica el motivo que activó el registro del problema, como 'Volumen de incidentes', 'Incidente grave', 'Notificación del proveedor' o 'Análisis proactivo de tendencias'. En BMC Helix, corresponde al campo 'Investigation Driver'. Este atributo facilita el análisis del Dashboard 'Tendencias de identificación proactiva'. Permite medir el paso de una gestión reactiva, centrada en responder a incidentes, a una gestión proactiva de problemas, que identifica riesgos antes de que se manifiesten. Analizar los flujos del proceso según el 'Motivo de la investigación' puede revelar distintos patrones. Por ejemplo, los problemas proactivos podrían permanecer más tiempo en la cola porque no provocan interrupciones inmediatas, mientras que los problemas derivados de un incidente grave suelen avanzar con mayor rapidez.
Por qué es importante
Distingue el trabajo reactivo del proactivo, un indicador clave de madurez.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Investigation Driver'
Ejemplos
ReactivoProactivoIncidentes recurrentes
|
|||
|
Prioridad
Priority
|
La prioridad calculada del problema según su impacto y urgencia. | ||
|
Descripción
Este atributo indica el nivel de prioridad del registro del problema (por ejemplo, Crítico, Alto, Medio o Bajo). En BMC Helix, suele ser un campo calculado a partir de las selecciones de impacto y urgencia. En el análisis, se utiliza en el Dashboard 'Volumen y prioridad de los casos'. Permite que las organizaciones comprueben si los recursos se asignan de acuerdo con las necesidades de la empresa. En teoría, los problemas críticos deberían tener tiempos de asignación inicial más cortos y tiempos de ciclo generales menores que los de prioridad baja. Filtrar por prioridad ayuda a centrar las iniciativas de mejora. Un cuello de botella en un proceso de prioridad baja podría ser aceptable, pero la misma demora en un proceso crítico supone un riesgo importante para la continuidad del negocio y el cumplimiento de los SLA.
Por qué es importante
Permite segmentar el análisis según la criticidad para la empresa y facilita el análisis de los SLA.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Priority'
Ejemplos
CríticoAltoMedioBajo
|
|||
|
Cantidad de reasignaciones
ReassignmentCount
|
El número total de veces que se cambió el grupo de soporte. | ||
|
Descripción
Este atributo cuenta cuántas veces se produce la actividad «Asignado al grupo de soporte» en un mismo caso. Mide directamente las fricciones del proceso y la eficiencia del enrutamiento. Este atributo alimenta el gráfico «Análisis de reasignaciones de grupos de soporte». Los valores altos, que reflejan asignaciones repetidas entre grupos, indican que la clasificación inicial no funciona o que no hay una persona o equipo claramente responsable de los problemas complejos. También anticipan un aumento del tiempo de ciclo. Los responsables utilizan esta información para detectar oportunidades de formación. Si la mesa de ayuda asigna sistemáticamente los problemas de «Base de datos» al equipo de «Red» y este los devuelve al equipo de «Base de datos», aumentará la cantidad de reasignaciones. Esto pone de manifiesto la necesidad de mejorar los guiones de diagnóstico inicial.
Por qué es importante
Permite detectar tareas innecesarias, fricciones y falta de responsabilidad en el proceso.
Dónde obtenerlo
Se calcula a partir del historial de actividades
Ejemplos
015
|
|||
|
Estado de la solución temporal
WorkaroundStatus
|
Indica si se identificó y publicó una solución temporal válida. | ||
|
Descripción
Este atributo registra el estado de la solución temporal (Workaround). Puede ser un valor booleano sencillo (Hay solución temporal) o una cadena de estado. En BMC Helix, suele determinarse a partir del texto del campo «Solución temporal» o de un indicador de estado específico. Este atributo es clave para el Dashboard «Rendimiento de publicación de soluciones temporales». Permite evaluar la eficacia con que el equipo mitiga el impacto mientras investiga la causa raíz. Una vista del proceso filtrada por «Sin solución temporal» destaca los casos en los que la organización sufre todo el impacto mientras dura la investigación. También facilita las auditorías de calidad. Cerrar un registro de problema sin una solución permanente (solicitud de cambio) ni una solución temporal suele indicar un fallo del proceso que debe revisarse.
Por qué es importante
Mide la eficacia de las medidas para mitigar el impacto durante la investigación.
Dónde obtenerlo
PBM: formulario de investigación de problemas, comprobación del contenido del campo «Solución temporal»
Ejemplos
ActivoNingunoRetirado
|
|||
|
ID de la solicitud de cambio relacionada
RelatedChangeRequestId
|
El identificador de la solicitud de cambio iniciada para corregir el problema. | ||
|
Descripción
Este atributo contiene el ID de la solicitud de cambio (por ejemplo, CRQ0000...) vinculada al registro del problema. Representa el paso de la investigación a la implementación de una solución permanente. Este atributo es necesario para el KPI «Tiempo desde la causa raíz hasta el inicio del cambio». Permite que la herramienta de Process Mining mida el tiempo transcurrido entre la identificación de la causa raíz y el inicio del proceso de cambio. Este es un punto habitual de traspaso en el que se pierde impulso. También ayuda a comprobar que el proceso esté completo. Si se cierra un registro de problema con el estado «Completado», pero sin una solicitud de cambio relacionada ni una solución temporal, puede indicar un incumplimiento del proceso: se identificó la causa raíz, pero nunca se corrigió el problema.
Por qué es importante
Vincula el proceso de gestión de problemas con el proceso de gestión de cambios.
Dónde obtenerlo
PBM: pestaña Asociaciones de investigación o Relaciones
Ejemplos
CRQ00000021345CRQ00000021346
|
|||
|
Región
Region
|
La región geográfica asociada al problema. | ||
|
Descripción
Este atributo especifica la ubicación geográfica (por ejemplo, «Norteamérica» o «EMEA») donde se originó el problema o donde se está gestionando. En BMC Helix, suele encontrarse en los campos «Región» o «Sitio» asociados a quien realizó la solicitud o al activo afectado. En el análisis, permite segmentar los datos por ubicación geográfica. Ayuda a identificar si determinadas regiones registran más problemas o tardan más en resolverlos. Esto puede poner de manifiesto diferencias en la dotación de personal de soporte o en la calidad de la infraestructura entre distintas ubicaciones. Es útil para que las organizaciones globales garanticen una prestación de servicios coherente. Si el «Tiempo de ciclo de investigación» en «APAC» duplica el de «NAM», conviene analizar la asignación de recursos o el cumplimiento del proceso en esa región.
Por qué es importante
Permite comparar el rendimiento del proceso por ubicación geográfica.
Dónde obtenerlo
PBM: formulario de investigación de problemas, campo «Región»
Ejemplos
AméricasEMEAAPAC
|
|||
|
Tiempo de ciclo de investigación
InvestigationCycleTime
|
El tiempo transcurrido desde el inicio de la investigación hasta la identificación de la causa raíz. | ||
|
Descripción
Este atributo calculado mide el tiempo transcurrido entre las actividades «Investigación iniciada» y «Causa raíz identificada». Representa el tiempo dedicado a las tareas que aportan valor en el proceso de gestión de problemas. Esta métrica alimenta el Dashboard «Tiempo de ciclo de investigación de la causa raíz». Ayuda a los responsables a comprender la complejidad técnica de los problemas y la eficiencia de los equipos de investigación. Los valores atípicos, como tiempos extremadamente cortos, pueden indicar que se está adivinando la causa; los tiempos muy largos pueden señalar investigaciones estancadas. Al comparar esta métrica entre «Grupos de soporte» y «Prioridades», la organización puede identificar qué equipos necesitan mejores herramientas, formación o soporte de proveedores para diagnosticar los problemas con mayor rapidez.
Por qué es importante
Es la principal métrica de eficiencia de la fase de investigación técnica.
Dónde obtenerlo
Se calcula a partir de las marcas de tiempo de las actividades
Ejemplos
4500000120000
|
|||
Actividades de Gestión de problemas
| Actividad | Descripción | ||
|---|---|---|---|
|
Asignado a un grupo de soporte
|
Asignación del registro del problema a un equipo técnico específico. Se captura mediante el seguimiento de los cambios en el campo 'Assigned Group'. | ||
|
Por qué es importante
Es fundamental para medir los traspasos, los cambios repetidos de equipo y el KPI 'Tiempo medio hasta la asignación inicial'.
Dónde obtenerlo
Formulario PBM:Problem Investigation, historial del campo 'Assigned Group' o registro de auditoría.
Capturar
Compare el campo 'Assigned Group' antes y después de la actualización
Tipo de evento
inferred
|
|||
|
Causa raíz identificada
|
Momento en que el registro del problema pasa a un estado que indica que se conoce la causa. Se infiere cuando Status cambia a 'Root Cause Identified'. | ||
|
Por qué es importante
Hito clave para el Dashboard 'Tiempo de investigación de la causa raíz'. Señala el paso del análisis a la búsqueda de una solución.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Status' = 'Root Cause Identified'.
Capturar
Compare el campo de estado para detectar la transición a Root Cause Identified
Tipo de evento
inferred
|
|||
|
Inicio de la investigación
|
Transición del registro del problema a una fase de análisis activa. Se infiere cuando el campo Status cambia a 'Under Investigation'. | ||
|
Por qué es importante
Marca el inicio de la fase de trabajo propiamente dicha y permite calcular el KPI 'Tiempo de investigación'.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Status' = 'Under Investigation'.
Capturar
Compare el campo de estado para detectar la transición a Under Investigation
Tipo de evento
inferred
|
|||
|
Registro del problema
|
Creación inicial de un registro de investigación de problemas en el sistema. Este evento se captura explícitamente cuando se guarda una nueva entrada en el formulario PBM:Problem Investigation. | ||
|
Por qué es importante
Marca el inicio de la instancia del proceso. Es fundamental para calcular los tiempos de ciclo generales y las métricas de respuesta inicial.
Dónde obtenerlo
Formulario PBM:Problem Investigation, marca de tiempo de 'Submit Date' o registro de creación con 'Status' = 'Draft'.
Capturar
Se registra al crear un registro de PBM:Problem Investigation
Tipo de evento
explicit
|
|||
|
Registro del problema cancelado
|
Finalización de un registro del problema antes de resolverlo. Se captura cuando el estado pasa a 'Cancelled' o 'Rejected'. | ||
|
Por qué es importante
Permite identificar esfuerzos desperdiciados o duplicados válidos. Representa un punto final alternativo.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Status' = 'Cancelled' o 'Rejected'.
Capturar
Compare el campo de estado para detectar la transición a Cancelled
Tipo de evento
inferred
|
|||
|
Registro del problema cerrado
|
Cierre administrativo definitivo del registro del problema. Este evento pone fin a la instancia del proceso. | ||
|
Por qué es importante
Es el evento de fin estándar. Es necesario para analizar el tiempo de ciclo completo y calcular la 'Densidad de vínculos con incidentes'.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Status' = 'Closed'.
Capturar
Compare el campo de estado para detectar la transición a Closed
Tipo de evento
inferred
|
|||
|
Resolución verificada
|
Momento en que se confirma que la solución permanente funcionó. Se infiere cuando Status cambia a 'Solution Implemented' o 'Completed'. | ||
|
Por qué es importante
Se utiliza para calcular la 'Tasa de cumplimiento del SLA de problemas'. Confirma que el trabajo técnico ha finalizado.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Status' = 'Solution Implemented' o 'Completed'.
Capturar
Compare el campo de estado para detectar la transición a Solution Implemented
Tipo de evento
inferred
|
|||
|
Solicitud de cambio iniciada
|
Vinculación de una solicitud de cambio de infraestructura con la investigación del problema. Esto señala el inicio de la fase de implementación. | ||
|
Por qué es importante
Es fundamental para el KPI 'Tiempo desde la causa raíz hasta el cambio' y para identificar silos entre los procesos de gestión de problemas y de cambios.
Dónde obtenerlo
Tabla PBM:Investigation_Associations o campo 'Infrastructure Change ID' completado.
Capturar
Se registra al crear la asociación en PBM:Investigation_Associations
Tipo de evento
explicit
|
|||
|
Solución temporal definida
|
Registro o actualización de texto en el campo Workaround del registro del problema. Este evento indica que se documentó una solución temporal. | ||
|
Por qué es importante
Permite calcular el KPI 'Tiempo hasta la publicación de la solución temporal'. Indica que se están tomando medidas para reducir el impacto del incidente.
Dónde obtenerlo
Formulario PBM:Problem Investigation, cambios en el campo de texto 'Workaround'.
Capturar
Compare el contenido del campo 'Workaround' para detectar actualizaciones con valores no nulos
Tipo de evento
inferred
|
|||
|
Base de datos de soluciones actualizada
|
Transición del registro al estado 'Solution Database', que indica que se propuso o identificó una solución permanente. | ||
|
Por qué es importante
Permite seguir el avance de la definición de la solución antes de implementarla.
Dónde obtenerlo
Formulario PBM:Problem Investigation, campo 'Status' = 'Solution Database'.
Capturar
Compare el campo de estado para detectar la transición a Solution Database
Tipo de evento
inferred
|
|||
|
Coordinador reasignado
|
Cambio de la persona coordinadora del problema dentro de un grupo de soporte. Se captura mediante el seguimiento del campo 'Problem Coordinator'. | ||
|
Por qué es importante
Ayuda a analizar la distribución de la carga de trabajo y los cuellos de botella relacionados con personas concretas.
Dónde obtenerlo
Formulario PBM:Problem Investigation, historial del campo 'Problem Coordinator'.
Capturar
Compare el campo 'Problem Coordinator' antes y después de la actualización
Tipo de evento
inferred
|
|||
|
Error conocido registrado
|
Creación de un registro de error conocido vinculado a la investigación del problema. Se trata de un evento de creación de un registro relacionado. | ||
|
Por qué es importante
Indica que el problema se formalizó para facilitar su comunicación y seguimiento a largo plazo.
Dónde obtenerlo
Creación de un registro en PBM:Known Error vinculado al ID de PBM:Problem Investigation.
Capturar
Se registra al crear un registro de PBM:Known Error
Tipo de evento
explicit
|
|||
|
Revisión posterior a la implementación realizada
|
Finalización de la fase PIR. Se captura mediante una transición de estado que sale de un estado PIR o al cerrar una Task PIR vinculada. | ||
|
Por qué es importante
Contribuye directamente al 'Cumplimiento de la revisión posterior a la implementación' y a las auditorías de calidad del proceso.
Dónde obtenerlo
Formulario PBM:Problem Investigation, indicador específico 'PIR Required' o finalización de una Task vinculada de tipo 'PIR'.
Capturar
Se deriva de la finalización del estado PIR o del cierre de una Task PIR
Tipo de evento
inferred
|
|||
Guías de extracción
¿Todo listo para comenzar?
Mejore la estabilidad de sus servicios aplicando hoy este Template a sus datos de BMC Helix ITSM. Si tiene preguntas sobre la configuración, nuestro equipo puede ayudarle.
Elimine hoy los cuellos de botella de Gestión de problemas
Reduzca los tiempos de ciclo un 30 % y mejore la estabilidad del servicio.
No se requiere tarjeta de crédito. Configuración en minutos.