Su Template de datos de Gestión de problemas

BMC Helix ITSM
Su Template de datos de Gestión de problemas

Su Template de datos de Gestión de problemas

Este Template ofrece una estructura completa para analizar los flujos de trabajo de investigación de causas raíz en BMC Helix ITSM. Describe los atributos y las actividades de proceso esenciales para crear un registro de eventos detallado, además de ofrecer instrucciones prácticas para extraer los datos. Siga esta guía para detectar cuellos de botella ocultos y agilizar el camino hacia la resolución definitiva de incidentes.
  • 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
¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Atributos de Gestión de problemas

Esta tabla contiene los campos de datos recomendados para completar el registro de eventos y analizar en profundidad el ciclo de vida de la gestión de problemas.
5 Obligatorio 9 Recomendado 5 Opcional
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
Obligatorio Recomendado Opcional

Actividades de Gestión de problemas

Estos son los pasos fundamentales del proceso y los cambios de estado que conviene seguir para obtener una visión completa de las fases de investigación y resolución.
9 Recomendado 4 Opcional
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
Recomendado Opcional

Guías de extracción

Cómo extraer los datos de gestión de problemas de BMC Helix ITSM

¿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.

Comience su prueba gratuita

No se requiere tarjeta de crédito. Configuración en minutos.