Gestión de Problemas.

Visión General

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

·   Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.

·   Determinar posibles soluciones a las mismas.

·   Proponer las RFC (Petición de cambio) necesarias para restablecer la calidad del servicio.

·   Realizar Revisiones PIR (Revisión Post Implementación) 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.

Objetivos

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 (Petición de cambio) 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. 

Proceso

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

• 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 RFC (Petición de cambio) 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.

Muestra los procesos implicados en la correcta Gestión de Problemas.

Proceso - Control 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 (Elementos de configuración) 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 (Elementos de configuración) 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.

Proceso - Control de Errores

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 (Acuerdo de nivel de servicio).

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFCs (Petición de cambio) 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 RFCs (Petición de cambio) 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á unaRFCs (Petición de cambio). 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 RFCs (Petición de cambio) elevado a la Gestión de Cambios PIR (Revisión Post Implementación).

Si los resultados de esta PIR (Revisión Post Implementación) 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.

Control del Proceso

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.