Las funciones principales de la Gestión de Problemas son:

 

 

• Determinar posibles soluciones a las mismas.

• Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.

• Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.

La Gestión de Problemas puede ser:

Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.

Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran.

 

Introducción y Objetivos.

 

Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes y causas del mismo.

Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.

Cabe diferenciar entre:

Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa.

Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas.

Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de Incidentes se resumen en el siguiente interactivo:


 

Entre la funciones principales de la Gestión de Problemas figuran:

 

• Identificar, registrar y clasificar los problemas.

• Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches.

• Analizar y determinar las causas de los problemas y proponer soluciones.

• Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI.

• Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.

• Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto.

• Analizar tendencias para prevenir incidentes potenciales.

Los principales beneficios de una correcta Gestión de Problemas:


 

• Un aumento de la calidad general de los servicios TI.

• Se minimiza el número de incidentes.

• Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI ahorrando recursos e innecesarios escalados.

• La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y Niveles de Servicio.

Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en:


 

• Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y resolver los problemas.

• Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la infraestructura TI.

• Aumento de los costes por la contratación de personal especializado, aunque estos se vean sobradamente compensados por los beneficios derivados.

Las principales actividades de la Gestión de Problemas son el:

Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.

Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.

Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas:

 

El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.

 

 

El Control de Problemas se compone en esencia de tres fases:

1. Identificación y Registro

Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:

 

• La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.

• Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.

• Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.

Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.

El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.

El registro debe incorporar, entre otra, información sobre:

 

• Los CIs implicados.

• Causas del problema.

• Síntomas asociados.

• Soluciones temporales.

• Servicios involucrados.

• Niveles de prioridad, urgencia e impacto.

• Estado: activo, error conocido, cerrado.

2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo.

Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio).

Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.

Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI.

3. Análisis y Diagnóstico: Error conocido

Los objetivos principales del proceso de análisis son:

• Determinar las causas del problema.

• Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.

Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por:

 

• Errores de procedimiento.

• Documentación incorrecta.

• Falta de coordinación entre diferentes áreas.

Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.

Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.

Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.

 

Identificación y Registro de errores.

El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados.

Análisis y Solución.

Se deben investigar diferentes soluciones para el error evaluando en cada momento:

 

• El posible impacto de las mismas en la infraestructura TI.

• Los costes asociados.

• Sus consecuencias sobre los SLAs.

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios.

Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:

• ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.

• ¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable?

• ¿Los beneficios justifican los costes asociados?

Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.

Revisión Post Implementación y Cierre.

Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR).

Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.

El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento.

En particular una buena gestión de problemas debe traducirse en una:

 

• Disminución del número de incidentes y una más rápida resolución de los mismos.

• Mayor eficacia en la resolución de problemas.

• Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio.

La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI.

Entre la documentación generada cabría destacar:

 

• Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidentes.

• Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.

• Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.

 

 

Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de identificación y solución de problemas.

Caso Práctico.

 

El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.

La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el modelo de Kepner y Tregoe:

• Identificación del problema.

• Clasificación del problema.

• Establecimiento de las posibles causas.

• Comprobación de la causa más probable.

• Verificación de la causa verdadera.

Identificación: En nuestro caso el problema es sencillo de definir:

 

• La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software.

Clasificación: La clasificación se adaptaría a los siguientes parámetros:

 

• Identificación: Problemas en el registro de pedidos.

• Origen: Módulo de pedidos online.

• Frecuencia: el problema no es recurrente, es la primera vez que se detecta.

• Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.

Posibles causas: Entre las causas más probables figuran:


 

• Errores en la programación del lado cliente de la aplicación.

• Errores en los módulos de registro del servidor web.

• Errores de configuración de la base de datos.

Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.

Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:

 

• Se intenta reproducir el problema.

• Se comprueba que el error sólo se reproduce con una determinada marca de helados.

• Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas.

Verificación:

• Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.

• Se introducen las modificaciones necesarias en la programación.

• Se comprueba el correcto registro del pedido.

El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:

 

• Elevar una RFC con la solución propuesta.

• Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.