La gestión de problemas es el proceso responsable de gestionar el ciclo de vida de todos los problemas que suceden o podrían suceder en un servicio de TI. Los objetivos principales de la gestión de problemas son evitar que se produzcan problemas e incidentes resultantes, eliminar los incidentes recurrentes y minimizar el impacto de los incidentes que no se pueden prevenir. ITIL define un problema como la causa de uno o más incidentes .
Alcance
La gestión de problemas incluye las actividades necesarias para diagnosticar la causa raíz de los incidentes identificados a través del proceso de gestión de incidentes y para determinar la resolución de esos problemas. También es responsable de garantizar que la resolución se implemente mediante los procedimientos de control adecuados, especialmente la Gestión de cambios y la Gestión de versiones .
La gestión de problemas también mantendrá información sobre los problemas y las soluciones y soluciones provisionales adecuadas, de modo que la organización pueda reducir el número y el impacto de los incidentes a lo largo del tiempo. En este sentido, la gestión de problemas tiene una interfaz sólida con la gestión del conocimiento , y para ambos se utilizarán herramientas como la base de datos de errores conocidos . Aunque la Gestión de Incidentes y la Gestión de Problemas son procesos separados, están estrechamente relacionados y normalmente utilizarán las mismas herramientas, y pueden utilizar sistemas de codificación de categorización, impacto y prioridad similares. Esto asegurará una comunicación eficaz cuando se trate de incidentes y problemas relacionados.
Valor para el negocio
La gestión de problemas trabaja junto con la gestión de incidentes y la gestión de cambios para garantizar que la disponibilidad y la calidad del servicio de TI aumenten. Cuando se resuelven los incidentes, se registra información sobre la resolución. Con el tiempo, esta información se utiliza para acelerar el tiempo de resolución e identificar soluciones permanentes, reduciendo el número y tiempo de resolución de incidencias. Esto se traduce en menos tiempo de inactividad y menos interrupciones en los sistemas críticos del negocio.
Actividades, métodos y técnicas de proceso
La gestión de problemas consta de dos procesos principales:
- Gestión reactiva de problemas, que generalmente se ejecuta como parte de la operación del servicio.
- Gestión proactiva de problemas que se inicia en la operación del servicio , pero generalmente se impulsa como parte de la mejora continua del servicio (CSI) .
Detección de problemas
- Sospecha o detección de una causa de uno o más incidentes por parte de la mesa de servicio , lo que resulta en un registro de problemas que se genera: la mesa de servicio puede haber resuelto el incidente pero no ha determinado una causa definitiva y sospecha que es probable que se repita.
- Análisis de un incidente por parte de un grupo de soporte técnico que revela que existe o es probable que exista un problema subyacente.
- Detección automatizada de una falla en la infraestructura o aplicación, utilizando herramientas de eventos / alertas automáticamente para generar un incidente que pueda revelar la necesidad de un Registro de problemas .
- Una notificación de un proveedor o contratista de que existe un problema que debe resolverse.
- Análisis de incidentes como parte de la gestión proactiva de problemas: boletines de observación, comunicados, artículos relevantes
Registro de problemas
Todos los detalles relevantes del problema deben registrarse para que exista un registro histórico completo. Esto debe estar sellado con la fecha y la hora para permitir un control y escalamiento adecuados. Se debe hacer una referencia cruzada a los incidentes que iniciaron el "Registro de problemas":
- Detalles del servicio
- Detalles del equipo
- Fecha / hora registrada inicialmente
- Detalles de prioridad y categorización
- Descripción del incidente
- Detalles de todas las acciones de diagnóstico o intentos de recuperación realizados.
Priorización de problemas
Los problemas se pueden categorizar según su gravedad y prioridad de la misma forma que las incidencias para facilitar su seguimiento, teniendo en cuenta el impacto de las incidencias asociadas y su frecuencia de ocurrencia. Desde el punto de vista de la infraestructura, uno puede preguntarse:
- ¿Se puede recuperar el sistema o es necesario reemplazarlo?
- ¿Cuanto costara?
- ¿Cuántas personas se necesitarán para solucionar el problema?
- ¿Cuánto tiempo llevará solucionar el problema?
- ¿Cuántos recursos adicionales estarán involucrados?
- ¿Cuál es el impacto de no resolver el problema?
Investigación y diagnóstico de problemas
El resultado de una investigación de un problema será un diagnóstico de causa raíz o un informe de RCA. La resolución debe ser la suma del nivel apropiado de recursos y habilidades utilizados para encontrarlo. Hay una serie de técnicas útiles para la resolución de problemas que se pueden utilizar para ayudar en el diagnóstico y la resolución de problemas.
- El Sistema de gestión de la configuración (CMS) debe usarse para ayudar a determinar el nivel de impacto y para ayudar a identificar el punto de falla.
- Se debe acceder y verificar la base de datos de errores conocidos o KEDB para averiguar si el problema ha ocurrido en el pasado, si es así, ya debería haber una solución.
- El análisis cronológico, los eventos que desencadenaron el problema se comprobarán en orden cronológico para tener una línea de tiempo de los eventos. El propósito es ver qué evento desencadena el próximo evento y así sucesivamente, o descartar algunos eventos posibles.
El análisis del valor del dolor contiene una visión más amplia del impacto de un incidente o un problema en la empresa. En lugar de analizar el número de incidentes / problemas de un tipo particular en un intervalo de tiempo particular, la técnica se centra en un análisis en profundidad del nivel de dolor que estos incidentes / problemas le han causado a la empresa. Una fórmula para calcular el nivel de dolor debe tener en cuenta:
- el número de personas afectadas
- la duración del tiempo de inactividad causado
- el costo para el negocio
El método de Kepner y Tregoe se utiliza para investigar problemas de raíces más profundas. Definieron las siguientes etapas:
- definiendo el problema
- describir el problema en términos de identidad, ubicación, tiempo (duración) y tamaño (impacto)
- estableciendo posibles causas
- probando la causa más probable
- verificando la verdadera causa
El análisis de Pareto o diagrama de Pareto es una técnica para separar las causas potenciales importantes de los problemas triviales. Deben seguirse los siguientes pasos:
- Forme una tabla que enumere las causas y su frecuencia como un porcentaje
- Organizar las filas en orden decreciente de importancia de las causas (la causa más importante primero)
- Agregue una columna de porcentaje acumulativo a la tabla
- Cree un gráfico de barras con las causas, en orden de su porcentaje del total.
- Dibuje una línea al 80% en el eje Y, luego suelte la línea en el punto de intersección con el eje X. En el gráfico puede ver las causas principales de las fallas de la red. Éstos deben apuntar primero.
Causas | Porcentaje del total | Computación% |
---|---|---|
Controlador de red | 35 | 0 + 35% = 35% |
Corrupción de archivos | 26 | 35% + 26% = 61% |
SO del servidor | 6 | 61% + 6% = 67% |
Registro de error conocido
Una vez que se completa la investigación y se ha encontrado una solución alternativa (o incluso una solución permanente), se debe generar un Registro de errores conocidos y colocarlos en la Base de datos de errores conocidos para identificar y resolver otros problemas similares. El objetivo principal es restaurar el servicio afectado lo antes posible con un impacto mínimo en el negocio.
Una buena práctica sería generar un Registro de errores conocidos lo antes posible en la investigación; una vez que se haya probado con éxito una solución alternativa o se haya identificado una causa raíz.
Revisión de problemas importantes
Una buena práctica es tener una revisión de todos los problemas importantes. Pero eso induce un costo. La revisión debe examinar:
- Los pasos correctos tomados
- Los problemas encontrados durante la implementación de la solución.
- La necesidad de mejorar
- Evitar la repetición de más incidentes similares.
- Tercero / Proveedor / Proveedor involucrado en la implementación
El conocimiento aprendido de la revisión debe incorporarse en una revisión del servicio con el cliente comercial para garantizar que el cliente esté al tanto de las acciones tomadas y los planes para evitar que ocurran incidentes similares en el futuro. Esto ayuda a mejorar la satisfacción del cliente y asegura a la empresa que las operaciones de servicio están manejando los incidentes importantes de manera responsable y trabajando activamente para evitar que vuelvan a ocurrir en el futuro.
Ver también
Referencias
- The New Rational Manager : describe la resolución de problemas y la toma de decisiones de KT (PSDM)
- Offord, Paul (2011). RPR: un método de diagnóstico de problemas para profesionales de TI . Essex, Inglaterra: Advance Seven Limited. ISBN 978-1-4478-4443-3.