Gestión de Problemas > Proceso > Control de Problemas [Curso ITIL v3

04
Operación

Operación de los Servicios TI

Anterior Siguiente

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 Incidencias: en principio, cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante un workaround (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 explícita 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 otras, 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, qué á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 Incidencias, 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 el problema y determinada su prioridad, se deben 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 Incidencias para minimizar el impacto del problema hasta que se implementen 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 frecuente que el problema esté 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 alguna 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.