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

Esta plantilla ofrece una estructura completa para analizar sus Workflows 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, junto con indicaciones prácticas para la extracción. Al seguir esta guía, podrá identificar cuellos de botella ocultos y agilizar el camino hacia la resolución permanente de los incidentes.
  • Campos de datos esenciales para el análisis de causas raíz
  • Hitos de proceso estandarizados para el seguimiento
  • Indicaciones específicas para extraer datos de BMC Helix ITSM
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos de la gestión de problemas

Esta tabla contiene los campos de datos recomendados necesarios para completar su 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 evento de cambio de estado que tuvo lugar.
Descripción

Este Atributo representa el paso específico realizado en el ciclo de vida de Problem Management, como «Problem Record Logged», «Root Cause Identified» o «Solution Database Updated». En BMC Helix, estos datos suelen 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 el núcleo del descubrimiento de procesos. Al analizar la secuencia de estas actividades, la herramienta de Process Mining construye el mapa del proceso y revela el flujo de trabajo real frente al proceso diseñado. Destaca los ciclos, el retrabajo y las desviaciones del procedimiento operativo estándar.

Los nombres precisos de las actividades son fundamentales para comprender lo que ocurrió realmente durante el ciclo de vida. Estos datos permiten medir los tiempos de transición entre pasos específicos, como el tiempo transcurrido 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 Workflow.

Dónde obtenerlo

Derivado del historial de estados de PBM:Problem Investigation o de PBM:AuditLogSystem

Ejemplos
Registro de problema creadoAsignado a un grupo de soporteInvestigación iniciadaCausa raíz identificada
Hora del evento
EventTime
La marca de tiempo en la que tuvo lugar 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», «Last Modified Date» o marcas de tiempo específicas registradas en las tablas de historial asociadas a los cambios de estado.

En el análisis, este Atributo se utiliza para ordenar cronológicamente los eventos y calcular duraciones. Permite medir los tiempos de ciclo entre dos puntos cualesquiera del proceso, como «Investigation Cycle Time» o «Workaround Publication Lead Time».

Las marcas de tiempo precisas son esenciales para identificar cuellos de botella. Al calcular la diferencia de tiempo entre eventos consecutivos, las personas analistas pueden localizar 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 duraciones 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 actúa como identificador central del caso para el proceso de Problem Management. En BMC Helix ITSM, normalmente corresponde al campo «Problem ID» (por ejemplo, PBI00000012345) del formulario PBM:Problem Investigation. Vincula todas las actividades relacionadas, desde el registro inicial del problema hasta el cierre final y la revisión posterior a la implementación.

En el análisis de Process Mining, este Atributo se utiliza para agrupar eventos individuales en una única instancia del proceso. Permite a las personas analistas visualizar el recorrido completo de una investigación de problemas específica. Sin este identificador, sería imposible correlacionar 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 a nivel de caso, como calcular el tiempo de ciclo total por problema o contar el número de problemas por nivel de prioridad.

Por qué es importante

Es la clave fundamental necesaria para construir la vista del proceso y realizar un seguimiento del 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 valida el origen del registro. Si la vista de Process Mining combina datos de BMC Helix para Problem Management con los de otro sistema de desarrollo de software, como Jira, este Atributo ayuda a segmentar el análisis por herramienta de origen.

También facilita la resolución de problemas técnicos. Si surgen problemas de calidad de datos, conocer el sistema de origen permite a las personas ingenieras de datos rastrear el problema hasta la rutina de extracción o la base de datos de origen específica.

Por qué es importante

Proporciona trazabilidad y contexto, especialmente en vistas de procesos con varios sistemas.

Dónde obtenerlo

Codificado durante el proceso de extracción

Ejemplos
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
Última actualización de datos
LastDataUpdate
La marca de tiempo en la que se extrajeron los datos o se actualizaron por última vez.
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 conozcan la actualidad de los datos que están consultando. Normalmente lo genera el script de extracción o la herramienta de la canalización de datos.

En el análisis, ayuda a evitar decisiones basadas en datos obsoletos. Por ejemplo, si una persona responsable consulta los «Open Problem Records», saber que los datos se actualizaron hace una hora en lugar de hace una semana cambia significativamente la interpretación de la carga de trabajo actual.

También se utiliza para las cargas de datos incrementales. Al registrar la hora de la última actualización, el proceso ETL puede obtener únicamente los registros que cambiaron desde la extracción anterior, lo que optimiza el rendimiento y reduce la carga del sistema.

Por qué es importante

Garantiza la actualización de los datos y ayuda a aplicar 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 ha incumplido el SLA?
IsSLABreached
Un 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ó su acuerdo de nivel de servicio. Se calcula comparando la marca de tiempo de «Resolution Verified» con «SLA Due Date» o se extrae directamente del estado de SLM.

Este atributo es fundamental para el Dashboard «SLA Compliance and Breach Trends». Permite segmentar el proceso de forma binaria: conforme o no conforme. Así resulta sencillo aislar las características de los procesos fallidos, por ejemplo: «¿Los casos con incumplimiento siempre implican al Support Group X?».

Sirve como filtro principal para analizar la causa raíz de los fallos del proceso. Los analistas pueden filtrar por «IsSLABreached = True» y examinar después el mapa del proceso para identificar dónde se perdió tiempo, por ejemplo, en largas esperas para la aprobación del proveedor.

Por qué es importante

Simplifica los informes de cumplimiento y el análisis de fallos.

Dónde obtenerlo

Formulario SLM:Measurement o cálculo

Ejemplos
truefalse
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, «Software Error», «Hardware Failure» o «Process Gap». En BMC Helix, normalmente se selecciona en los menús «Root Cause» o «Generic Categorization».

Este Atributo es esencial para la vista «Fix Effectiveness and Quality». Permite a la organización 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 tipo «Software Error» tardan sistemáticamente el doble en resolverse que los problemas de tipo «Hardware Failure».

También se utiliza para calcular «Root Cause Categorization Rate». Un porcentaje elevado de valores «Unknown» u «Other» en este campo sugiere la necesidad de mejorar la formación técnica o de disponer de opciones de categorización más detalladas.

Por qué es importante

Permite analizar las tendencias de los problemas sistémicos y respalda una gestión proactiva de los problemas.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campos de la pestaña «Root Cause» o de categorización

Ejemplos
Módulo de softwareInfraestructura de redError humano
CI del servicio
ServiceCI
El servicio empresarial principal o elemento de configuración afectado.
Descripción

Este Atributo identifica el elemento de configuración del servicio (CI) relacionado con el problema, como «Email Service», «SAP ERP» o «Wi-Fi Network». 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 comprender qué servicios son más frágiles y generan más investigaciones de problemas. Esta información alimenta el Dashboard «Throughput and Priority Volume» al añadir una dimensión de producto.

Relacionar este Atributo con «Investigation Cycle Time» puede mostrar si determinados servicios complejos, como un sistema bancario central, requieren por naturaleza periodos de investigación más largos que servicios básicos, como la impresión.

Por qué es importante

Relaciona el rendimiento del proceso con productos o servicios empresariales específicos.

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 usuaria asignada para coordinar la investigación.
Descripción

Este Atributo identifica a la persona responsable del registro del problema. En BMC Helix ITSM, corresponde al campo «Problem Coordinator». Esta persona es responsable del ciclo de vida del problema, aunque delegue tareas en otras personas.

Este Atributo respalda el Dashboard «Support Group Workload Distribution». Ayuda a la dirección a identificar si determinadas personas están sobrecargadas de investigaciones mientras otras tienen capacidad disponible. También permite analizar el rendimiento individual e identificar necesidades de formación o un desempeño destacado.

En Process Mining, este campo actúa como Atributo de recurso. Ayuda a visualizar cómo fluye el trabajo entre las personas y puede revelar puntos únicos de fallo cuando un proceso depende demasiado de una persona experta concreta.

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 objetivo antes de las cuales debe resolverse 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 «Target Resolution Date» o a una marca de tiempo calculada de un hito del SLA.

Este Atributo es la referencia del Dashboard «SLA Compliance and Breach Trends». Al comparar esta marca de tiempo con la marca de tiempo de la actividad «Resolution Verified», el sistema calcula si se cumplió o se incumplió el SLA.

Visualizar esta fecha permite saber con qué margen trabaja el equipo. ¿Resuelve los problemas con varios días de antelación o termina sistemáticamente apenas unos minutos antes del incumplimiento? Esta información orienta la planificación de la capacidad.

Por qué es importante

Es el punto de referencia para calcular todas las métricas de cumplimiento y puntualidad.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Target Resolution Date»

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 refleja el grupo de soporte específico, por ejemplo, «Server Admin» o «Database Support», responsable del registro del problema en el momento del evento. En BMC Helix, corresponde al campo «Assigned Group».

Este Atributo es fundamental para los Dashboard «Support Group Workload Distribution» y «Support Group Reassignment Analysis». Permite a las personas analistas segmentar el mapa del proceso por equipo, revelar qué grupos gestionan el mayor volumen e identificar cuáles generan cuellos de botella en el proceso de investigación.

Analizar las transferencias entre grupos de soporte ayuda a identificar comportamientos de ida y vuelta, en los que un ticket pasa de un equipo a otro sin resolverse. Esto suele indicar responsabilidades poco claras o una gestión del conocimiento insuficiente dentro de la organización.

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 desencadenante del registro del problema, como «Incident Volume», «Major Incident», «Vendor Notification» o «Proactive Trend Analysis». En BMC Helix, corresponde al campo «Investigation Driver».

Este Atributo respalda el Dashboard «Proactive Identification Trends». Permite a la organización medir el cambio desde una gestión reactiva de incidentes hacia una gestión proactiva de problemas, que identifica los riesgos antes de que se manifiesten.

Analizar los flujos del proceso por «Investigation Driver» puede revelar comportamientos diferentes. Por ejemplo, los problemas «Proactive» podrían permanecer más tiempo en la cola porque no provocan interrupciones inmediatas, mientras que los problemas motivados por un «Major Incident» avanzan con mayor rapidez.

Por qué es importante

Distingue entre el trabajo reactivo y el proactivo, un indicador clave de madurez.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Investigation Driver»

Ejemplos
ReactivoProactivoIncidentes recurrentes
Número de incidentes relacionados
RelatedIncidentCount
El número de incidentes vinculados a este registro del problema.
Descripción

Este Atributo cuantifica el impacto del problema al contar el número de incidentes asociados. En BMC Helix, normalmente corresponde al recuento de registros del formulario HPD:Help Desk relacionados con el registro PBM.

Este Atributo alimenta el KPI «Incident Linkage Density». Un número elevado indica un problema de gran impacto que genera una carga considerable para la mesa de servicio. Relacionarlo con «Priority» permite comprobar que los problemas de gran volumen se tratan realmente como críticos.

También ayuda a priorizar la acumulación de trabajo. Un registro de problema con 500 incidentes vinculados probablemente debería tener prioridad sobre un problema Critical con un solo incidente, ya que resolver el primero liberaría más capacidad de la mesa de servicio.

Por qué es importante

Cuantifica el impacto operativo y las dificultades que el problema causa a las personas usuarias.

Dónde obtenerlo

Se calcula contando las filas relacionadas en HPD:Associations o HPD:Help Desk

Ejemplos
15120
Prioridad
Priority
La prioridad calculada del problema en función del impacto y la urgencia.
Descripción

Este Atributo indica el nivel de prioridad del registro del problema, por ejemplo, Critical, High, Medium o Low. En BMC Helix, normalmente corresponde a un campo calculado a partir de las selecciones de Impact y Urgency.

En el análisis, se utiliza para el Dashboard «Throughput and Priority Volume». Permite a las organizaciones comprobar si los recursos están correctamente alineados con las necesidades del negocio. Por ejemplo, en teoría, los problemas Critical deberían tener tiempos de asignación inicial más rápidos y tiempos de ciclo generales más cortos que los problemas de prioridad Low.

Filtrar por prioridad ayuda a centrar los esfuerzos de mejora. Un cuello de botella en un proceso de prioridad Low podría ser aceptable, pero la misma demora en un proceso Critical representa un riesgo importante para la continuidad del negocio y el cumplimiento de los SLA.

Por qué es importante

Segmenta el análisis según la criticidad empresarial y respalda el análisis de los SLA.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Priority»

Ejemplos
CríticoAltoMedioBajo
Estado de la solución temporal
WorkaroundStatus
Indica si se ha identificado y publicado una solución temporal válida.
Descripción

Este atributo registra el estado de la solución temporal (Workaround). Puede ser un valor booleano simple (Has Workaround) o una cadena de estado. En BMC Helix, suele derivarse de la presencia de texto en el campo «Workaround» o de un indicador de estado específico.

Este atributo es clave para el Dashboard «Workaround Publication Performance». Permite evaluar la eficacia con la que el equipo mitiga el impacto mientras investiga la causa raíz. Una vista del proceso filtrada por «No Workaround» muestra los casos en los que el negocio sufre todo el impacto durante la investigación.

También respalda las auditorías de calidad. Cerrar un registro de problema sin una solución permanente (Change Request) Y sin una solución temporal suele indicar un fallo del proceso que requiere revisión.

Por qué es importante

Mide la eficacia de la mitigación del impacto durante la investigación.

Dónde obtenerlo

Formulario PBM:Problem Investigation, comprobación del contenido del campo «Workaround»

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 Change Request, por ejemplo, CRQ0000..., vinculada al registro del problema. Representa la transición de la investigación a la implementación de una solución permanente.

Este Atributo es necesario para el KPI «Root Cause to Change Lead Time». Permite a la herramienta de Process Mining medir la demora entre el descubrimiento de la causa raíz y el inicio del proceso de cambio. Este es un punto de transferencia habitual en el que se pierde impulso.

También ayuda a verificar la integridad del proceso. Un registro de problema cerrado con el estado «Completed», pero sin una solicitud de cambio relacionada ni una solución temporal, podría indicar un incumplimiento del proceso: se encontró la causa raíz, pero nunca se corrigió realmente.

Por qué es importante

Vincula el proceso de Problem Management con el proceso de Change Management.

Dónde obtenerlo

PBM:Investigation Associations o pestaña Relationship

Ejemplos
CRQ00000021345CRQ00000021346
Número de reasignaciones
ReassignmentCount
El número total de veces que se cambió el grupo de soporte.
Descripción

Este atributo cuenta cuántas veces aparece la actividad «Assigned to Support Group» en un mismo caso. Es una medida directa de la fricción del proceso y de la eficiencia del enrutamiento.

Este atributo alimenta el gráfico «Support Group Reassignment Analysis». Los valores altos, que indican un intercambio constante entre grupos, muestran que el triaje inicial está fallando o que no existe una responsabilidad clara para los problemas complejos. Es un indicador anticipado del aumento del tiempo de ciclo.

Los responsables lo utilizan para identificar oportunidades de capacitación. Si el Service Desk reasigna sistemáticamente los problemas de «Database» primero a «Network» y después «Network» los devuelve a «Database», el número de reasignaciones aumentará, lo que señalará la necesidad de mejorar los guiones de diagnóstico inicial.

Por qué es importante

Identifica desperdicios, fricción y falta de responsabilidad en el proceso.

Dónde obtenerlo

Calculado a partir del historial de actividades

Ejemplos
015
Región
Region
La región geográfica asociada al problema.
Descripción

Este Atributo especifica la ubicación geográfica, por ejemplo, «North America» o «EMEA», donde se originó o se gestiona el problema. En BMC Helix, suele encontrarse en los campos «Region» o «Site» asociados a la persona solicitante o al activo afectado.

En el análisis, permite realizar una segmentación geográfica. Ayuda a identificar si determinadas regiones registran un mayor volumen de problemas o tiempos de resolución más largos. Esto puede revelar diferencias en la dotación de personal de soporte o en la calidad de la infraestructura entre distintas ubicaciones.

Es valioso para las organizaciones globales que buscan garantizar una prestación de servicios uniforme. Si el «Investigation Cycle Time» en «APAC» duplica el de «NAM», conviene investigar la asignación de recursos o el cumplimiento del proceso en esa región.

Por qué es importante

Permite comparar geográficamente el rendimiento del proceso.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Region»

Ejemplos
AméricasEMEAAPAC
Tiempo de ciclo de la 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 de duración calculada mide el tiempo transcurrido entre las actividades «Investigation Commenced» y «Root Cause Identified». Representa el tiempo central que aporta valor en el proceso de gestión de problemas.

Esta métrica alimenta el Dashboard «Root Cause Investigation Cycle Time». Ayuda a los responsables a comprender la complejidad técnica de los problemas y la eficiencia de los equipos de investigación. Las anomalías, como tiempos extremadamente cortos, pueden indicar que se está adivinando la causa, mientras que los tiempos excesivamente largos apuntan a investigaciones estancadas.

Al comparar esta métrica entre «Support Groups» y «Priorities», la organización puede identificar qué equipos necesitan mejores herramientas, capacitación o apoyo 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

Calculado a partir de las marcas de tiempo de las actividades

Ejemplos
4500000120000
Obligatorio Recomendado Opcional

Actividades de la gestión de problemas

Estos son los pasos fundamentales del proceso y los cambios de estado que debe seguir para obtener visibilidad completa sobre 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

Esencial para medir las transferencias, los efectos de ida y vuelta y el KPI «Mean Time to Initial Assignment».

Dónde obtenerlo

Formulario PBM:Problem Investigation, historial del campo «Assigned Group» o registro de auditoría.

Recopilar

Comparar 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 fundamental para el Dashboard «Root Cause Investigation Cycle Time». Señala el paso del análisis a la definición de la solución.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Status» = «Root Cause Identified».

Recopilar

Comparar el campo de estado para detectar la transición a Root Cause Identified

Tipo de evento inferred
Investigación iniciada
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 respalda el KPI «Investigation Cycle Time».

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Status» = «Under Investigation».

Recopilar

Comparar el campo de estado para detectar la transición a Under Investigation

Tipo de evento inferred
Registro de problema creado
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».

Recopilar

Se registra cuando se crea el registro PBM:Problem Investigation

Tipo de evento explicit
Registro del problema cancelado
Finalización de un registro de problema antes de su resolución. 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».

Recopilar

Comparar el campo de estado para detectar la transición a Cancelled

Tipo de evento inferred
Registro del problema cerrado
Cierre administrativo final del registro del problema. Este evento termina la instancia del proceso.
Por qué es importante

Evento final estándar. Es necesario para analizar el tiempo de ciclo completo y calcular «Incident Linkage Density».

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Status» = «Closed».

Recopilar

Comparar 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 ha funcionado. Se infiere cuando «Status» cambia a «Solution Implemented» o «Completed».
Por qué es importante

Se utiliza para «Problem SLA Adherence Rate» y confirma que el trabajo técnico ha finalizado.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Status» = «Solution Implemented» o «Completed».

Recopilar

Comparar 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 «Root Cause to Change Lead Time» y para identificar silos entre los procesos de Problem Management y Change Management.

Dónde obtenerlo

Tabla PBM:Investigation_Associations o cumplimentación del campo «Infrastructure Change ID».

Recopilar

Se registra cuando se crea la asociación en PBM:Investigation_Associations

Tipo de evento explicit
Solución temporal definida
Introducción o actualización de texto en el campo «Workaround» del registro del problema. Este evento indica que se ha documentado una solución temporal.
Por qué es importante

Respalda el KPI «Workaround Publication Lead Time» e indica la mitigación del impacto del incidente.

Dónde obtenerlo

Formulario PBM:Problem Investigation, cambios en el campo de texto «Workaround».

Recopilar

Comparar el contenido del campo «Workaround» para detectar actualizaciones no nulas

Tipo de evento inferred
Base de datos de soluciones actualizada
Transición del registro al estado «Solution Database», que indica que se ha propuesto o identificado una solución permanente.
Por qué es importante

Realiza un seguimiento del avance de la definición de la solución antes de su implementación.

Dónde obtenerlo

Formulario PBM:Problem Investigation, campo «Status» = «Solution Database».

Recopilar

Comparar 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 de recursos individuales.

Dónde obtenerlo

Formulario PBM:Problem Investigation, historial del campo «Problem Coordinator».

Recopilar

Comparar el campo «Problem Coordinator» antes y después de la actualización

Tipo de evento inferred
Known Error promovido
Creación de un registro Known Error vinculado a la investigación del problema. Se trata de un evento de creación de un registro relacionado.
Por qué es importante

Indica la formalización del problema para facilitar la comunicación general y el seguimiento a largo plazo.

Dónde obtenerlo

Creación de un registro en PBM:Known Error vinculado al ID de PBM:Problem Investigation.

Recopilar

Se registra cuando se crea el registro 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 fuera de un estado PIR o el cierre de una Task PIR vinculada.
Por qué es importante

Respalda directamente «Post Implementation Review Compliance» y 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».

Recopilar

Derivado 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 sus datos de gestión de problemas de BMC Helix ITSM

¿Listo para comenzar?

Transforme hoy la estabilidad de su servicio aplicando esta plantilla a sus datos de BMC Helix ITSM. Nuestro equipo está disponible para ayudarle si tiene alguna pregunta sobre la configuración.

Elimine hoy los cuellos de botella de la gestión de problemas

Reduzca los tiempos de ciclo un 30 % y mejore la estabilidad del servicio.

Inicie su prueba gratuita

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