Estrategias para identificar problemas II

Dentro del marco ITSM Software la Gestión de Problemas es un aspecto fundamental. Identificar correctamente los problemas que se van a gestionar en busca de mejoras perceptibles en la calidad de la prestación de servicios es crítico.

En un artículo anterior explicamos cómo identificar los problemas cuya solución sería más eficaz para mejorar la Gestión de Incidencias. Otro proceso susceptible de mejora es la gestión de cambios ¿Cómo podemos priorizar los problemas para gestionar antes aquellos cuya solución tiene un mayor ROI?

Para mejorar la Gestión de Cambios.

a) Definir una lista de comprobación (checklist) que se aplicará de manera sistemática en todos los cambios cuando se cierren. Lo ideal es que tenga la forma de preguntas con respuesta sí/no (tal vez debamos tener distintas checklist en función del tipo de cambio).
b) Revisar periódicamente los cambios agrupándolos por las respuestas a cada pregunta de la checklist para poder identificar aquellos que sugieren una oportunidad de mejora. Por ejemplo, el porcentaje de cambios tiene respuesta “sí” a las preguntas ¿la planificación fue adecuada? o ¿las pruebas fueron suficientes?
c) Aplicar el principio de Pareto sobre los datos de b) para identificar las áreas de mejora (por ejemplo la planificación de las actividades o los recursos dedicados a pruebas)

La lista c) nos dará una idea de qué debemos cambiar a la hora de la gestión de cambios para que estos sean más efectivos. Este es, por tanto, el “input” para generar registros de problemas cuya resolución mejore la realización de cambios de manera efectiva. Como se puede apreciar, que la checklist sea adecuada es la clave del éxito de este método.

¿Cómo podemos elaborar la checklist para que sea efectiva? La respuesta es sencilla: busquemos los cambios cuya realización ha provocado incidencias. Veamos un ejemplo:

Supongamos que tenemos un cambio en el que había que migrar una aplicación de un servidor a otro. Se realiza la migración y la aplicación ya está funcionando en el nuevo servidor. Sin embargo, una semana después de realizar el cambio se empiezan a generar incidencias donde hay usuarios que reportan que una aplicación que leía información de la que fue migrada, ahora muestra un mensaje de error. Las incidencias están provocadas por una dependencia entre las dos aplicaciones que no se conocía o no se tuvo en cuenta.

Si trazamos el cambio con las incidencia que provocó y hacemos lo mismo con cada cambio que provoque incidencias, tendremos un buen punto de partida para identificar las preguntas y saber lo que debe contener la checklist. En este caso podrían ser:

• ¿El análisis del impacto fue efectivo?
• ¿Si el análisis del impacto no fue efectivo, se debe a que la CMDB no representaba todas las relaciones entre los activos?

De esta manera hemos visto cómo definir una checklist que utilizaremos para identificar las oportunidades de mejora en los cambios que podremos abordar mediante la Gestión de Problemas.

José Luis Fernández Piñero