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
- Indicaciones específicas para extraer datos de BMC Helix ITSM
Atributos de la gestión de problemas
| 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
|
|||
Actividades de la 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
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
|
|||
Guías de extracción
¿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.
No se requiere tarjeta de crédito. Configuración en minutos.