Proceso: Gestión de Problemas

Objetivo

Alcance 

El procedimiento de Gestión de Problemas se encargará de resolver los problemas que impacten sobre los Sistemas de Información gestionados desde la Subdirección de Tecnologías de la Información y la Infraestructura que los soporta. 
Abarca desde que se identifica un problema, ya sea de manera proactiva o reactiva, hasta la resolución que da solución a la causa del problema identificado.

Descripción de Actividades

Roles

Diagrama de flujo (actividades y estados)

[]

Loading...

Descripción del flujo

Registrar 

Existen diversas formas de detección de problemas en la organización: análisis de una incidencia, sospecha o detección por parte de primera línea, detección automática por parte de las herramientas de monitorización, análisis de proveedores, GP, RGPs o RP. El paso principal es registrar el problema identificado por el usuario, recopilando toda la información posible acerca de este, tanto del CI sobre el que se detecta el problema como la prioridad de este. Una vez se realiza el registro a través de área personal de ayudaDIGITAL el problema queda asignado al GP para ser revisado.

Revisar

El GP revisa siempre en primera instancia el problema, determina si es o no un problema o si se trata de un duplicado, en cualquiera de estos casos cerrará el problema recibiendo notificación el solicitante.

Si aplica, se asigna al RGP, que será siempre responsable del CI sobre el que se ha detectado el problema: una aplicación o una plataforma.

Decidir abordar

Desde Web Técnica, el RGP debe decidir qué hacer con el problema.

• Es posible que determine que no se debe abordar por diversos motivos: coste vs beneficio, indisponibilidad de recursos para abordarlos. En dicho caso el problema se suspende. Siempre el RGP tendrá la capacidad de retomar el problema.
• O bien decide dedicar esfuerzos a resolver el problema y deberá determinar el modo de hacerlo.

Convocar Kick off 

El RGP ha decidido que se deber abordar, por lo que tendrá que organizar la forma en que la resolución se debe llevar a cabo.

• Puede ocurrir que la resolución del problema se circunscriba al ámbito de competencia de un único resolutor. En ese caso lo asignará a este y le comunicará de la manera que tengan acordada que el problema se debe investigar. Por ejemplo, a través de reuniones de periódicas de operación del servicio.
• Puede ocurrir que el problema sea multidisciplinar y necesite de varios resolutores para afrontarlo. En este caso se convocará una reunión ad hoc específica para iniciar ese problema. A esta reunión deberán asistir tantos los resolutores responsables del mantenimiento de las aplicaciones como de plataformas afectadas, así como sus responsables y el GP. De esta reunión deberá salir un plan de trabajo acordado entre todas las partes. Esta reunión la convocará siempre el GP.

Investigar

Durante la actividad de investigación siempre se busca la causa raíz del problema y se proponen soluciones provisionales o definitivas al mismo. Se aplicarán técnicas de resolución de problemas y reproducciones en condiciones adecuadas del problema. Durante esta actividad el problema tiene las siguientes características:

• Asignación del problema:

El problema lo tiene siempre asignado el resolutor (proveedor). Si se trata de un problema multidisciplinar lo tendrá siempre el resolutor sobre el que recae el mayor peso de la resolución del problema.

• Escalar del problema

Un resolutor puede escalar sin necesidad de escalar previamente al RGP el problema a otro resolutor. Se deberá realizar el cambio de CI necesario para que esté alineado con el resolutor que lo está investigando, el que recibe, que revise.

• Actualización del problema.

Todos aquéllos que participen en el problema deben dejar constancia de los avances. Lo puede hacer tanto el resolutor que lo tiene asignado, como el RGP, como otros resolutores (de haberlos) o el GP.

El GP se demandará actualizar con una periodicidad mínima mensual, el estado de los problemas, siendo de obligado cumplimiento para todos los resolutores.

En caso de que haya algún bloqueo, el proveedor lo elevará al RGP deberá actuar para ayudar a superarlo, pudiéndose apoyar en el GP.

• Documentación de soluciones temporales

Se hallan soluciones temporales se documentarán y se asociarán al problema. Un problema debería al menos tener una solución temporal y a medida que se avanza en el análisis es posible se mejore en la calidad de las soluciones temporales disponibles.

• Causa subyacente del problema

El resolutor deberá documentar la causa subyacente de hallarse. No hay una forma definida: puede ser un comentario, un documento anexado.

• Error conocido

Un problema con al menos una solución temporal y con la causa subyacente identificada, pasa a ser un error conocido. Se puede determinar que este problema no deba resolverse de manera definitiva. Los errores conocidos de estas características quedarán fuera de las revisiones periódicas de problemas, en estado suspendido, pero se evaluará si deben resolverse de manera definitiva, por ejemplo, porque el volumen de incidencias repetitivas así lo indique.

Resolver

Un vez identificada la causa subyacente del problema, el resolutor podrá resolverlo, con o sin Gestión de Cambios de la misma manera que se resuelve una incidencia o una petición.

Cada resolutor acordará con el RGP la mejor manera de ejecutar la resolución: por ejemplo si es necesario una autorización expresa o no o que deba resolverlo el RGP (realizar la acción de resolver en la herramienta).

El problema una vez se resuelve se asigna al RGP que debe aceptar de manera expresa el cierre. Si este no se efectúa se cierra automáticamente a los 7 días.

Cancelar

El RGP dispondrá de la opción de cancelar un problema. Dicha opción está reservada para casos muy concretos, como pueden ser problemas de cierta antigüedad que con la evolución de los productos ya no tenga sentido mantenerlos. Las cancelaciones siempre deberán tener un registro de justificación.

Cambiar prioridad

El RGP podrá establecer la prioridad que estime necesaria a los problemas para maneja.

Seguimiento e indicadores

Seguimiento:

• El proceso tendrá la menos una reunión mensual de coordinación para revisar la salud del proceso e identificar mejoras a éste. A estas reuniones asistirán los responsables de operación de las áreas de sistemas y proyectos, el GP y el responsable de mejora de procesos de SSHH.
• Así mismo se mantendrán reuniones operativas con cada uno de los resolutores para revisar el avance de los problemas asignados. A dichas reuniones asistirá el GP, con los responsables de operación de las áreas de la STIC, RGPs y sus proveedores de servicio.
• Dentro del la resolución concreta de una problema, podrá haber tantas reuniones técnicas como sean necesarias.
• El GP deberá garantizar que los problemas vigentes tengan actualizaciones, de no ser así, lo elevará al RGP entendiéndose que se trata de un problema que debería estar suspendido.
• En el MTI están publicados varios tableros para facilitar el seguimiento de los problemas a todos los interesados.

Indicadores:

El Gestor de Problemas podrá elaborará informes de gestión del proceso. Entre las métricas a obtener en dichos informes se podrá encontrar a modo de ejemplo:

• Tasa EC = nª EC/N º de problemas en un periodo
• Tasa problemas suspendidos = nº problemas suspendidos/Nº de problemas de un periodo
• Tiempo medio de resolución de un problema

Actas

• Actas gestión de problemas

Formación