¿Qué es la ITIL ® gestión de problemas de ?

Definición del problema de ITSM

Un problema es la causa o la causa potencial de múltiples incidentes. Los problemas pueden surgir de incidentes importantes que afecten a muchos usuarios o de incidentes recurrentes. Además, los problemas se pueden identificar en los sistemas de diagnóstico de infraestructura antes de que los usuarios se vean afectados.

Los incidentes obstaculizan la productividad empresarial y proporcionar soluciones rápidas ayuda a garantizar la continuidad sin problemas de las operaciones comerciales. Sin embargo, cuando ocurren varios incidentes a la vez o el mismo incidente ocurre varias veces, no es posible seguir adelante proporcionando soluciones de mosaico u ofreciendo las mismas resoluciones una y otra vez.

ITIL ® gestión de problemas es una forma de procedimiento para garantizar un mínimo de incidentes surgen de las operaciones de TI de infraestructura por profundizando en incidentes de encontrar las causas y correcciones, y también a reducir la gravedad de los incidentes a través de documentación adecuada de los problemas existentes y proporcionar soluciones.

La gestión de problemas es un enfoque metódico para identificar la causa de un incidente y gestionar el ciclo de vida de todos los problemas. El objetivo del de ITIL ® proceso de gestión de problemas es minimizar el impacto de los incidentes y eliminar los recurrentes. Si bien ITIL ® no establece ninguna técnica específica para realizar la gestión de problemas, recomienda tres fases a seguir:

  • Identificación de problemas de ITIL

    Problema de identificación

  • Control de problemas de ITIL

    Control de problemas

  • Control de errores de gestión de problemas de ITIL

    Error control

Estas fases se analizarán en detalle más adelante en la guía.

La gestión reactiva se ocupa de los incidentes que actualmente afectan a los usuarios, mientras que la gestión proactiva de problemas aborda los problemas que podrían surgir como incidentes en el futuro si se los dejara tranquilos.

Un proceso de gestión de problemas sólido tiene el potencial de reducir significativamente la afluencia de tickets de incidentes, lo que ahorra al personal de la mesa de servicio de TI una cantidad significativa de tiempo y esfuerzo. Esta ventaja se refleja en otros beneficios, como la reducción del tiempo medio de reparación (MTTR), una mayor satisfacción del cliente, una sólida base de datos de errores conocidos y la reducción del costo de los servicios y problemas de TI. Además, una organización que practica la gestión proactiva de problemas probablemente encontrará un gran valor al identificar y eliminar problemas antes de que interrumpan los procesos comerciales.

La gestión de problemas como ITIL ® práctica de es más útil cuando se utiliza con otras ITIL ® prácticas de en la cadena de valor general del servicio. Se intercambia información entre los distintos ITIL ® prácticas, a saber, la gestión de incidencias, gestión de cambios , gestión de activos de TI , la gestión del conocimiento , y la mejora continua del servicio. Esta información intercambiada entre las partes se acumula valor a medida que avanza a través de cada ITIL ® práctica, a su vez, la construcción de un ideal proceso de gestión de servicios de TI .

Antes de seguir adelante, las siguientes definiciones serán útiles para comprender el contexto de esta guía.

  • Solución alternativa : soluciones temporales que restauran los servicios y garantizan la continuidad del negocio. Una solución alternativa reduce el impacto de un incidente o problema.
  • Análisis de causa raíz (RCA) : la causa raíz es el problema subyacente del problema. RCA son las técnicas de investigación que ayudan a descubrir la causa raíz de un problema.
  • Error conocido : problemas que han ocurrido antes y tienen una solución o causas raíz conocidas.
  • Base de datos de errores conocidos (KEDB) : una base de datos creada al documentar los errores conocidos mediante la gestión de incidentes y problemas.
  • En esta guía, examinaremos cada faceta de la gestión de problemas en detalle, proporcionando todo el conocimiento que necesita para ponerse al día sobre cómo implementar la gestión de problemas en su empresa.

Gestión de incidentes frente a gestión de problemas

Gestión de incidentes importantes frente a gestión de problemas

En ITIL ® , el incidente términos y el problema podría parecer ser sinónimo, pero ambos son distintos en el papel que desempeñan en la consecución de la calidad del servicio ideal. Es importante saber dónde gestión de incidentes gestión de y la problemas interactúan la y en qué se diferencian, especialmente dónde termina un incidente y comienza un problema.

Administracion de incidentes

Un incidente es una interrupción no planificada de un servicio completo o solo un componente de uno. Veamos un escenario para entenderlo mejor. Hay una reunión importante en 15 minutos y se debe imprimir un informe. Desafortunadamente, la impresora del departamento no funciona. Se genera rápidamente un ticket para corregir una solución temporal y obtener los informes impresos. Este es un incidente.

El proceso de gestión de incidentes consiste en manejar incidentes y restaurar el servicio lo antes posible. En nuestro escenario, el personal de la mesa de servicio conecta rápidamente la computadora portátil a la impresora del departamento contiguo para ayudar al usuario a preparar los informes a tiempo para la reunión. Por lo tanto, el objetivo de la gestión de incidentes es garantizar que una interrupción o un incidente se resuelva lo más rápido posible con una solución alternativa o una solución.

Manejo de problemas

La gestión de problemas no se trata de restaurar servicios o solucionar problemas, sino de determinar y eliminar la causa. Un problema se registra en una mesa de servicio cuando hay incidentes recurrentes que tienen problemas comunes o si un incidente importante ocurre que afecta a muchos usuarios. En nuestro escenario, la única impresora del departamento se hundió y todos los usuarios de ese departamento se vieron afectados, lo que el personal de la mesa de servicio registró como un problema para encontrar la causa y la solución. Se puede cerrar un incidente cuando se proporciona una solución alternativa, pero se plantea un problema para reparar la impresora de forma permanente para que este problema no vuelva a ocurrir.

Volviendo a nuestro escenario, el problema de la impresora se someterá a RCA para encontrar una solución permanente y se rastreará como un ticket de problema mientras el negocio continúa con la solución en su lugar. Si el equipo de gestión de problemas no puede encontrar una solución, la solución se documenta y el problema se agrega al KEDB. De esta manera, la gestión de problemas no solo consiste en eliminar incidentes encontrando la causa raíz subyacente, sino también en determinar la solución más factible que se puede implementar para minimizar las interrupciones. A veces, a pesar de conocer la causa raíz, la solución más factible es implementar una solución alternativa y documentarla como un error conocido.

A pesar de ser diferentes, la gestión de incidentes y la gestión de problemas se complementan y están estrechamente alineadas. La gestión de incidentes garantiza la continuidad de las operaciones comerciales, mientras que la gestión de problemas se ocupa de los problemas y problemas subyacentes.

Gestión reactiva de problemas frente a gestión proactiva de problemas

Gestión de problemas reactiva vs proactiva

¿Qué es la gestión reactiva de problemas?

La gestión reactiva de problemas reacciona a los incidentes que aparecen y luego continúa con el proceso de gestión de problemas. Esencialmente, un enfoque de gestión reactiva de problemas tiene como objetivo encontrar y eliminar las causas fundamentales de los errores conocidos y se ocupa de un problema solo cuando aparece como incidentes importantes o recurrentes.

¿Qué es la gestión proactiva de problemas?

La gestión proactiva de problemas busca problemas, fallas y errores conocidos en los sistemas de TI revisando incidentes pasados, registros de datos de monitoreo de red y otras fuentes de información, luego procede a resolverlos permanentemente antes de que surjan como incidentes. Este proceso es parte de la mejora continua del servicio. La gestión proactiva de problemas también tiene como objetivo resolver todos los errores conocidos bajo la KEDB si es factible hacerlo.

Ambos tipos de gestión de problemas siguen las mismas fases de resolución de problemas una vez que se les presenta un problema: identificación de problemas, control de problemas y control de errores. La única diferencia es el enfoque para identificar el problema. No obstante, ambos procesos ofrecen distintas ventajas para la gestión de servicios y requieren recursos únicos para funcionar.

Elegir entre enfoques de gestión de problemas reactivos y proactivos

cómo implementar una gestión de problemas reactiva y proactiva

Las organizaciones que son nuevas en la gestión de problemas deben centrar sus esfuerzos en implementar un proceso reactivo de gestión de problemas. Es sensato utilizar el talento de resolución de problemas del personal de la mesa de servicio existente cuando no están ocupados con incidentes diarios; al hacer esto, obtienen una valiosa experiencia antes de implementar una gestión proactiva de problemas.

A medida que madura la prestación de servicios de una organización, debe pasar a un proceso de gestión de problemas proactivo. Esta transición debe ser realizada por un equipo con un buen conjunto de habilidades analíticas que sea altamente competente en la infraestructura de TI y las herramientas y tecnología que respaldan a la organización.

Sin embargo, muchas organizaciones no se someten a esta transición, ya que es complicado cuantificar los beneficios de la gestión proactiva de problemas, que puede percibirse como la solución de problemas potenciales y no reales. Sin embargo, algunas de las organizaciones más eficaces del mundo practican la gestión proactiva de problemas y encuentran un gran beneficio en ella.

¿Cuáles son los beneficios de la gestión de problemas de TI?

ITIL beneficia la gestión de problemas

Hay algunos obstáculos que las organizaciones pueden encontrar en el proceso de establecer la gestión de problemas. Es posible que la organización no tenga los recursos para asignarlos a un equipo de gestión de problemas, o puede que ya tenga una forma poco ortodoxa de gestionar los problemas y sea reacia a cambiar. A veces, podría ser simplemente una denegación de la solicitud relacionada con el costo.

En consecuencia, es vital incluir a todas las partes interesadas en el proceso de gestión de problemas y expresar cómo aporta valor a las diferentes facetas de la organización. Estos beneficios incluyen:

  • Elimina las fallas en los servicios de una organización mediante la documentación adecuada.
  • Refina el diseño del servicio identificando y resolviendo los puntos débiles, asegurando la ruta más eficaz y eficiente para la prestación del servicio.
  • Aumenta la tasa de reparación por primera vez de fallas en el servicio al brindar soluciones permanentes a los incidentes en lugar de detenerse en las soluciones.
  • Disminuye el impacto de los incidentes que afectan a varios usuarios oa un solo usuario en un momento crucial.
  • Evita la mayoría de los incidentes y problemas que afectan a una organización a lo largo del tiempo, aumentando la productividad del usuario.
  • Refuerza la confianza de los usuarios en los servicios de TI de la organización.
  • Disminuye el tiempo necesario para recuperarse de fallas mediante el mantenimiento sistemático de un KEDB.
  • Evita incidentes recurrentes mediante arreglos únicos, lo que ahorra valiosos esfuerzos en el servicio de asistencia técnica para resolverlos.
  • Alienta a los servicios de TI a madurar a medida que la organización se desarrolla mediante el aprendizaje de los problemas resueltos.
  • Desarrolla talento de TI dentro de la organización a través de conocimientos técnicos y conocimientos valiosos.

Dé el primer paso en su viaje de gestión de problemas

Funciones y responsabilidades de gestión de problemas de TI

Responsabilidades de gestión de problemas

Los roles de un equipo de gestión de problemas están directamente relacionados con la estructura organizativa presente. La edad, la cultura, la tecnología y el número de ubicaciones de la organización en todo el mundo afectan la composición de su equipo de gestión de problemas. En el caso de pequeñas organizaciones de TI, las responsabilidades del equipo pueden estar combinadas o, en el caso de grandes corporaciones multinacionales, pueden estar especializadas.

De cualquier manera, le toca a la conveniencia y la flexibilidad del equipo de TI para adaptar un acuerdo que garantiza que se abordan los problemas de manera eficiente en términos de ITIL ® recomendaciones. Conocer la estrategia general de la organización es un buen punto de partida para iniciar la formación del equipo. Además, es importante tener cuidado con los recursos que la organización está lista para expulsar para el desarrollo de un equipo de gestión de problemas.

Los roles y responsabilidades del equipo deben extenderse, divergir y madurar a medida que crece la tecnología de la organización; de lo contrario, pueden surgir confusiones en la responsabilidad durante la prestación del servicio.

Las funciones y responsabilidades generales de los equipos de gestión de problemas se enumeran a continuación.

Papel Responsabilidad
Administrador de problemas Responsable de la efectividad y eficiencia de toda la práctica. Similar al líder del equipo.
Propietario del problema Responsable del ciclo de vida de los tickets de problemas que se les asignen.
Agente de problemas Responsable de las tareas asociadas con un ticket de problema.
Equipo de diagnóstico Una variedad de personas con experiencia diversa, responsables de RCA de un problema.

Flujo del proceso de gestión de problemas de TI

Así como una organización crea valor para sus clientes, la administración de servicios de TI crea valor para sus usuarios a través de las mejores prácticas e indirectamente ayuda a crear valor para la organización. Para crear este valor, debe haber un proceso con entradas y salidas definidas. Cuando se ITIL ® instala una mesa de servicio preparada para , el flujo optimizado de un proceso de problemas se ve así:

Pasos del flujo del proceso de gestión de problemas de ITIL

De acuerdo con ITIL ® , puede implementar procesos de gestión de problemas con cualquier tecnología que considere el sistema más adecuado para su organización. La puesta en marcha de tecnología debe tener funcionalidades que permiten a las tres fases de ITIL ® gestión de problemas.

Las tres fases son:

Fases de la gestión de problemas
Definición de identificación de problemas

Problema de identificación

La fase de identificación de problemas identifica y registra problemas en una herramienta de gestión. Una herramienta de mesa de servicio asociada con múltiples prácticas de administración de servicios, incluida la administración de incidentes, la administración de activos, la CMDB y la administración de cambios, brinda a las organizaciones una ventaja en esta fase.

Si bien el personal de la mesa de servicio normalmente informaría problemas en función de una oleada de incidentes, un enfoque proactivo para la gestión de problemas identifica los problemas mediante:

  • Analizar las tendencias de incidentes, aprovechar los sistemas de monitoreo de red y utilizar otro software de diagnóstico.
  • Detectar riesgos de incidentes que puedan repetirse.
  • Evaluar la información recibida de socios y proveedores.
  • Evaluar información de desarrolladores de software internos, ingenieros y equipos de prueba.

Dependiendo de la estructura, el dominio y la cultura de su organización, podría haber incluso más modos a través de los cuales se pueden identificar los problemas. No obstante, es importante contar con un sistema para que los problemas se traigan, identifiquen, prioricen y registren para su posterior investigación y diagnóstico.

Control de problemas en ITIL

Control de problemas

La gestión de problemas es un esfuerzo de colaboración, por lo que para que los resultados sean efectivos, varios departamentos y partes interesadas deben participar en la fase de control del problema.

El control de problemas incluye actividades como priorización, investigación, análisis y documentación de errores conocidos y soluciones. Existen numerosas técnicas que ayudan a priorizar y analizar problemas. Una buena regla a seguir es abordar primero los problemas que, una vez resueltos, frenan significativamente la interrupción de los servicios en la organización.

La viabilidad es otro aspecto a tener en cuenta al abordar los problemas. Arreglar un problema de forma permanente puede requerir más recursos que conformarse con una solución alternativa. Un análisis rápido de costo-beneficio puede determinar si debe proceder con una solución permanente o no.

Las soluciones provisionales se documentan en los registros de problemas. Generalmente, si un problema persiste por más tiempo, se recomienda implementar una solución rápida. Esta solución puede incluso formar parte de la resolución de la gestión de incidentes; sin embargo, el equipo de gestión de problemas debe revisar la solución y perfeccionar la resolución si es necesario. Como puede ver, una solución alternativa eficaz para incidentes puede convertirse en una solución permanente para algunos problemas.

Control de problemas y control de errores

Error control

Esta fase gestiona los errores conocidos del KEDB comprobándolo periódicamente en busca de posibles correcciones permanentes si pasan el análisis de coste-beneficio.

Una vez que se analiza un problema, se documenta como un error conocido. Estos errores conocidos se reevalúan periódicamente para tener en cuenta el impacto que crean y para probar la eficacia de las soluciones.

La relación entre los ITIL ® procesos de y la gestión de problemas

Un sistema integrado de mejores prácticas de prestación de servicios mejora los servicios comerciales y las capacidades de los servicios de TI. Un proceso de gestión de problemas eficaz tiene interacciones con varios otros ITIL ® procesos de .

Gestión de incidentes vs gestión de problemas vs gestión de cambios

Los procesos que interactúan con la gestión de problemas se analizan brevemente a continuación:

Administracion de incidentes

La gestión de incidentes es el proceso metódico de registrar, categorizar, priorizar, asignar y resolver problemas en una organización. El objetivo de la gestión de incidentes es reiniciar los servicios interrumpidos lo antes posible; a menudo, esto significa que se organiza una solución alternativa en lugar de una solución permanente. Cada actividad en esta práctica se documenta en una escala granular y se envía al equipo de gestión de problemas, que inicia RCA para desarrollar una solución permanente. Puede ver que, a pesar de que la gestión de problemas es un proceso propio, depende de un proceso sólido de gestión de incidentes.

Gestión del cambio

El objetivo de la del gestión cambio es aumentar la tasa de éxito de cualquier cambio implementado en la organización . Un cambio se refiere a cualquier modificación realizada en la infraestructura de TI, los procesos, los servicios, los productos, las aplicaciones, los proveedores o cualquier otra cosa que afecte implícita o explícitamente la prestación de servicios de la organización.

De acuerdo con el ITIL ® marco , la responsabilidad de la gestión de problemas concluye con encontrar la causa raíz que conduce a la solución de un problema, y ​​la implementación de la solución se lleva a cabo con control de cambios. Dado que implementar un cambio implica gestionar el riesgo en múltiples unidades de negocio, requiere un proceso propio para un manejo eficiente. Sin embargo, el equipo de gestión de problemas debe participar en la revisión posterior a la implementación de un cambio para garantizar la coherencia entre la solución del problema y el cambio implementado asociado.

Gestión de activos de TI

La gestión de activos de TI es la práctica de gobernar el ciclo de vida de un activo en una organización. Sus actividades incluyen obtener el máximo valor de los activos, controlar los costos de los activos y administrar los riesgos de los activos. Estos riesgos pueden estar en términos de cumplimiento, selección de proveedores, políticas de uso y prácticas de eliminación.

Las prácticas de gestión de activos y gestión de problemas pueden cruzarse cuando los problemas surgen de los activos de hardware y software utilizados por la organización. Cuando la causa raíz de un problema parece provenir de un producto o servicio, el registro detallado del inventario de la administración de activos de TI acelera el proceso de resolución del problema. Aparte de esto, la gestión de activos de TI ayuda a la gestión de problemas a estudiar el impacto de un incidente, examinar los efectos de implementar una solución y proporcionar información cuando sea necesario a través de RCA.

Resolución de problemas de ITIL

Pongamos las cosas en perspectiva con un escenario.

Zylker es un proveedor de fotografías de archivo de rápido crecimiento en la India. Un gerente en Mumbai ha tenido problemas para generar informes mensuales desde el servidor SQL en Nueva Delhi. Se ha planteado un incidente y el personal de la mesa de servicio ha notificado a los técnicos en Nueva Delhi. Como solución temporal, los informes se generan localmente y se envían para garantizar la continuidad del negocio.

El equipo proactivo de gestión de problemas de Zylker decide ejecutar un análisis de tendencias sobre los incidentes ocurridos durante los últimos seis meses. Encuentran múltiples incidentes relacionados con el servidor en Nueva Delhi. Esto los lleva a iniciar un ticket de problema y proceder con el análisis de investigación utilizando los datos acumulados de todos los incidentes documentados.

El técnico de Nueva Delhi ve que el servidor SQL utiliza varios tipos de protocolos, incluidos iSCSI y Fibre Channel, para vincular las instalaciones de almacenamiento de datos. Dado que ambos protocolos funcionan en una red Ethernet, existen dudas sobre si el conmutador de bloque local se configuró para la transferencia de paquetes de datos grandes. El técnico recibe datos del equipo de gestión de activos de TI y verifica que el interruptor no sea el culpable. Esto está respaldado por la evidencia de que generar informes localmente no fue un problema.

La red de área amplia (WAN) es la siguiente en la línea de análisis, ya que un gerente de Mumbai tiene problemas para generar el informe mensual. El técnico, por su experiencia en temas de red, tiene dudas sobre el flujo de tráfico al final de cada mes, por lo que instalan software en los enrutadores y conmutadores de la empresa para analizar el tráfico que pasa por ellos y agregar estadísticamente la información.

El software genera gráficos y tablas que indican los principales protocolos que se utilizaron, junto con el ancho de banda que cada protocolo consumió durante un mes. Esto revela un uso significativo del ancho de banda al final del mes aproximadamente al mismo tiempo que se genera el informe mensual. Después de un examen cuidadoso, se reveló que las copias de seguridad de imágenes completas se programaron aproximadamente al mismo tiempo que el informe mensual, y esto causó un cuello de botella significativo en la WAN.

Ahora que se identifica la causa raíz del problema, el técnico genera un ticket de cambio para reprogramar la copia de seguridad de la imagen para las primeras horas de la mañana antes de que comience el negocio, nivelando el tráfico en la red.

A continuación, se ofrece una descripción general de los pasos realizados en este escenario:

Actividad Práctica involucrada
El gerente de Mumbai tuvo problemas para generar informes mensuales desde el servidor SQL de Nueva Delhi. Se planteó un incidente y los informes se generaron localmente y se enviaron al gerente. El boleto estaba cerrado. Administracion de incidentes
El equipo proactivo de gestión de problemas ejecutó un análisis de tendencias sobre incidentes durante los últimos seis meses. Encontraron múltiples incidentes relacionados con el servidor en Nueva Delhi. Gestión de problemas, gestión de incidentes
El técnico de Nueva Delhi observó la red y el protocolo del servidor SQL y no estaba seguro de si el conmutador de bloque local estaba configurado para la transferencia de datos en paquetes grandes. Gestión de problemas Gestión de activos de TI
El técnico recibió datos del equipo de administración de activos de TI y verificó que el interruptor no era el culpable. Gestión de problemas Gestión de activos de TI
El técnico tenía sospechas sobre el flujo de tráfico al final de cada mes e instaló software en los enrutadores y conmutadores que analizaban el tráfico y agregaban estadísticamente la información. Gestión de problemas, gestión de activos de TI
Después de un examen cuidadoso, se reveló que las copias de seguridad de imágenes completas se programaron aproximadamente al mismo tiempo que la generación del informe, y esto provocó un cuello de botella significativo en la WAN. Manejo de problemas
El técnico presentó un ticket de cambio para reprogramar la copia de seguridad de la imagen hasta las primeras horas de la mañana antes de que comience el negocio. Gestión de problemas gestión del cambio

Todas las ITIL ® prácticas de tienen una relación intrincada con otras ITIL ® prácticas de . A medida que la gestión de problemas madura en la prestación de servicios, asegúrese de mejorar la forma en que interactúa con otras prácticas para una prestación de servicios saludable y orientada a los negocios.

Técnicas de gestión de problemas de TI utilizadas en ITIL ®

El proceso de gestión de problemas puede exigirse con una buena herramienta de mesa de servicio, pero las técnicas utilizadas para la investigación y el diagnóstico deben variar según la organización. Se recomienda que las técnicas de investigación sean flexibles en función de las necesidades de la organización en lugar de ser demasiado prescriptivas.

Dado que los problemas pueden aparecer en cualquier forma o tamaño, es imposible ceñirse a una técnica para encontrar una solución cada vez; en cambio, el uso de una combinación de técnicas producirá los mejores resultados. Un simple problema de conectividad LAN puede resolverse con una rápida sesión de lluvia de ideas, pero un problema de red o VoIP puede necesitar una mirada más profunda.

Aquí hay varias técnicas que puede practicar en el proceso de gestión de problemas de su organización.

Técnicas de resolución de problemas de ITIL

Lluvia de ideas

Al establecer un diálogo entre departamentos, obtiene diversas perspectivas y nueva información, generando muchas soluciones potenciales.

Para tener una sesión de lluvia de ideas productiva, necesita un moderador. El moderador maneja lo siguiente:

  • Conduciendo la dirección de la reunión
  • Documentar los conocimientos obtenidos
  • Destacando las medidas a tomar
  • Seguimiento del entregable discutido
  • Evitar una sesión que consume mucho tiempo

Las sesiones de lluvia de ideas son más productivas cuando se utilizan técnicas colaborativas de resolución de problemas, como el análisis de Ishikawa y el método de los cinco por qué. Estas técnicas se analizarán más adelante en esta sección.

Métodos proactivos de gestión de problemas

Método de Kepner-Tregoe

El método Kepner-Tregoe (KT) es una técnica de resolución de problemas y toma de decisiones que se utiliza en muchos campos debido a su enfoque paso a paso para resolver un problema de manera lógica. Es ideal para resolver problemas complejos en la gestión de problemas tanto proactiva como reactiva.

El método sigue cuatro procesos:

  • Valoración de la situación: valoración y aclaración del escenario
  • Análisis de problemas: conexión de causa con efecto
  • Análisis de decisiones: ponderación de las opciones alternativas
  • Análisis de problemas potenciales: anticipar el futuro

Sin embargo, el análisis de problemas es la única parte que las preocupaciones ITIL ® gestión de problemas, y que consta de cinco pasos.

Define el problema

Identificar cuál es realmente el problema puede ser un problema en sí mismo. Dado que la gestión de problemas es inherentemente un esfuerzo de colaboración, tener una definición completa del problema elimina las nociones preconcebidas que podría tener cualquier miembro participante, ahorrando una cantidad considerable de tiempo.

Por ejemplo, si la copia de seguridad automática de datos de una organización en un servidor ha fallado, el problema se puede definir como:

Copia de seguridad fallida en el servidor

De hecho, esta definición describe la desviación de la situación normal, pero exige más preguntas e información. Un buen modelo de definición debe ser inequívoco y fácil de entender.

Para eliminar la ambigüedad, la definición anterior se puede actualizar a:

La copia de seguridad de datos el 15 de noviembre falló en el servidor # 34-C

Esta definición proporciona más claridad y evita que los empleados tengan preguntas redundantes. Sin embargo, esta definición se puede mejorar aún más. Suponga que la causa del error en la copia de seguridad de los datos se puede atribuir a un evento como la aplicación de un nuevo parche; entonces, el análisis inicial del problema indudablemente conduciría a este evento.

Para ahorrar tiempo y esfuerzo, actualice la definición a:

La copia de seguridad de datos el 15 de noviembre falló en el servidor # 34-C después de la aplicación del parche 3.124 por parte del ingeniero Noah

Esta definición detallada no deja lugar a preguntas redundantes y proporciona una buena cantidad de información sobre dónde podría estar el problema. Estos minutos adicionales dedicados a la definición inicial ahorran un tiempo y un esfuerzo valiosos, proporcionan un sentido lógico de dirección al análisis y eliminan cualquier noción preconcebida sobre el problema.

Describe el problema

El siguiente paso consiste en presentar una descripción detallada del problema. El método KT proporciona las preguntas que deben formularse sobre cualquier problema para ayudar a identificar las posibles causas.

Las preguntas siguientes ayudan a describir cuatro partes de cualquier problema:

  • ¿Cuál es el problema?
  • ¿Dónde ocurrió el problema?
  • ¿Cuándo ocurrió el problema?
  • ¿Hasta qué punto ocurrió el problema?

Cada una de estas preguntas exige dos tipos de respuestas:

IS: Como en, "¿Cuál es el problema?" o "¿Dónde está el problema?"

y

PODRÍA SER pero NO ES: Como en, "¿Dónde podría estar el problema pero no está?"

Este ejercicio ayuda a comparar y resaltar qué, dónde, cuándo y cómo está ocurriendo la desviación del desempeño normal en los procesos comerciales.

Establecer posibles causas

La comparación entre el rendimiento normal y el rendimiento desviado realizada en el paso anterior ayuda a seleccionar las posibles causas del problema. Hacer una tabla con toda la información en un solo lugar puede ser útil para hacer la comparación.

Es Podría ser pero no es Diferencias Cambios
Qué La copia de seguridad del servidor n. ° 34-C falló después del parche 3.124 Copias de seguridad fallidas en otros servidores con el parche 3.124 El nuevo ingeniero (Noah) aplicó el parche Se siguió un nuevo procedimiento de parche
Dónde Servidor del cuarto piso Servidores del sótano Normalmente realizado por ingenieros de nivel 3 El ingeniero de nivel 1 lo aplicó
Cuando 15 de noviembre, 12:32 am En otro momento Ninguno anotado
Grado Solo en el servidor # 34-C Cualquier otro servidor Ninguno anotado

Nuevas causas posibles se hacen evidentes cuando se reúne la información. Para nuestro problema de ejemplo, la causa raíz se puede reducir a:

Error de procedimiento provocado por la transferencia inadecuada de conocimientos por parte de los ingenieros de Nivel 3.

Cualquiera que sea el problema, se puede realizar un análisis sólido de las posibles causas basándose en una comparación relevante.

Pruebe la causa más probable

El penúltimo paso es preseleccionar las causas probables y probarlas antes de llegar a la conclusión. Cada causa probable debe seguir esta pregunta:

Si _______ es la causa raíz de este problema, ¿explica cuál ES el problema y cuál PODRÍA SER pero NO ES?

Nuevamente, es beneficioso completar toda la información en una tabla.

Causa raíz potencial Cierto si ¿Causa raíz probable?
El servidor # 34-C tiene un problema Solo el servidor # 34-C se ha visto afectado Tal vez
Procedimiento incorrecto El mismo procedimiento afecta a otro servidor Probablemente
Error de ingeniero El problema no volvió a ocurrir con el mismo procedimiento Probablemente no

Verifica la verdadera causa

El paso final es eliminar todas las causas improbables y proporcionar evidencia de las causas más probables. Con esta verificación, es el momento de proponer una solución al problema. Sin evidencia de la posible causa raíz, no se debe intentar la solución.

Análisis de la causa raíz de ITIL

Análisis de Ishikawa o análisis de diagrama de espina de pescado

El análisis de Ishikawa usa el marco de espina de pescado para enumerar la causa y los efectos de un problema, y ​​puede usarse junto con sesiones de lluvia de ideas y el método de los cinco por qué. La simplicidad en la ejecución de RCA usando un diagrama de Ishikawa no debería engañarlo sobre su destreza para manejar problemas complejos.

Para comenzar el análisis, defina el problema y utilícelo como la cabeza de la espina de pescado. Dibuje el lomo y agregue las categorías de las que podría originarse el problema, como las costillas a la espina de pescado.

Generalmente, es más fácil comenzar las categorías con las cuatro dimensiones de la gestión de servicios: socios, procesos, personas y tecnología. Sin embargo, estas categorías pueden ser cualquier cosa relevante para su problema, entorno, organización o industria.

Una vez que estas categorías forman las costillas de la espina de pescado, comience a adjuntar posibles causas a cada categoría. Cada posible causa también puede diversificarse para detallar el motivo de esa ocurrencia. Esto podría conducir a un diagrama complejo de cuatro a cinco niveles de causas y efectos, que posteriormente profundizaría en la causa raíz del problema.

Ejemplo de diagrama de espina de pescado

Se recomienda dividir las costillas densas en costillas adicionales según sea necesario. Alternativamente, combinar las costillas vacías con otras costillas adecuadas mantiene la espina de pescado limpia y fácil de leer. Además, debe asegurarse de que las costillas estén pobladas de causas, no solo de síntomas del problema.

Este análisis es nuevamente un esfuerzo colaborativo y requiere un moderador para dirigir las sesiones de lluvia de ideas de manera efectiva. Cada participante tiene la oportunidad de participar, proporcionando una visión integral del problema.

Categorías de clasificación de problemas de ITIL

Análisis de Pareto

El principio de Pareto es una observación de que aproximadamente el 80 por ciento de los efectos provienen de aproximadamente el 20 por ciento de las causas. Esta observación se aplica a una amplia gama de temas, incluida la gestión de problemas.

Cuando se trata de reducir la cantidad de incidentes que ocurren en una organización, es muy eficiente aplicar el análisis de Pareto antes de saltar a la solución de los problemas. El análisis de Pareto prioriza las causas de los incidentes y ayuda a gestionar los problemas en función de su impacto y probabilidad.

Este análisis se lleva a cabo generando un diagrama de Pareto a partir de una tabla de Pareto. Una tabla de Pareto consiste en el recuento acumulativo de clasificación de todos los problemas. Un diagrama de Pareto es un gráfico de barras que muestra el porcentaje acumulado de la frecuencia de varias clasificaciones de problemas.

Para crear un diagrama de Pareto, siga los pasos que se indican a continuación:

  • Recopile datos de tickets de problemas de su herramienta de mesa de servicio.
  • Remodele los datos en categorías basadas en varios atributos.
  • Cree una tabla de Pareto para encontrar la frecuencia de problemas en cada clasificación durante un período de tiempo.
  • Calcule la frecuencia de aparición de problemas en cada categoría.
  • Genere el porcentaje de frecuencia acumulativo en orden decreciente.
  • Trace los datos en un gráfico para crear un gráfico de Pareto.

El paso más importante es remodelar los datos en un conjunto contable de clasificaciones y atributos.

Clasificación Atributo
Impacto Afecta al negocio Afecta al departamento Afecta al usuario
Prioridad Bajo Alto Urgente
Categoría Red Activos de hardware Activos de software
Duración En SLA Fuera de SLA Sin SLA
Clasificación Atributo Contar Acumulativo % de contribución
Duración Sin SLA 670 1.470 38,72%
Prioridad Alto 550 2.020 53,21%
Duración Fuera de SLA 500 2.520 66,39%
Categoría Red 430 2,950 77,71%
Prioridad Urgente 300 3250 92,73%
Categoría Activos de software 270 3,520 92,73%
Categoría Activos de hardware 150 3.670 96,68%
Impacto Afecta al departamento 80 3.750 98,79%
Impacto Afecta al usuario 35 3,785 99,71%
Impacto Afecta al negocio 9 3,794 99,95%
Duración En SLA 2 3.796 100%

Este cuadro ayuda a identificar los problemas que deben resolverse primero para reducir significativamente la interrupción del servicio. Este análisis complementa los métodos de Ishikawa y Kepner-Tregoe al proporcionar una forma de priorizar la categoría de problemas, mientras que los otros métodos analizan la causa raíz.

Es importante recordar que la regla 80/20 sugiere causas probables y, en ocasiones, puede ser incorrecta.

Gestión de problemas de ITIL v4

Técnica de los cinco porqués

Cinco porqués es una técnica sencilla para RCA. Define una declaración de problema, luego pregunta repetidamente por qué hasta que se descubre la causa raíz subyacente del problema. El número de por qué no necesita limitarse a cinco, pero puede basarse en el problema y la situación.

La técnica de los cinco por qué complementa muchas otras técnicas de resolución de problemas como el método de Ishikawa, el análisis de Pareto y el método KT.

Utilizando el ejemplo anterior del error de copia de seguridad de datos en un servidor, apliquemos la técnica de los cinco por qué.

¿Por qué falló la copia de seguridad de datos en el servidor # 32-C? Debido a la aplicación del parche 3.124.
¿Por qué se debió al parche 3.124? El procedimiento utilizado fue diferente.
¿Por qué fue diferente el procedimiento? Un ingeniero de nivel 1 fue responsable de ello.
¿Por qué fue responsable el ingeniero de nivel 1? Los ingenieros de Nivel 3 estaban ocupados con un incidente importante y tuvieron una transferencia inadecuada de conocimientos.
¿Por qué hubo una transferencia inadecuada de conocimientos? No hay un horario o formato estandarizado utilizado en la organización.

El proceso iterativo anterior revela la ausencia de un formato estandarizado, lo que ha llevado al problema de fallas en la copia de seguridad de los datos.

Para nuestros propósitos, el ejemplo anterior es una ejecución simple del método. En un escenario real, la siguiente pregunta depende de la respuesta a la pregunta anterior, por lo que es imperativo colaborar con las partes interesadas que tienen un conocimiento detallado del dominio en el que reside el problema.

Al adoptar partes del método KT junto con la técnica de los cinco por qué, como proporcionar evidencia para cada respuesta antes de validarla con una pregunta de retorno, puede garantizar un análisis preciso durante las sesiones de resolución de problemas.

5 por que resolver problemas

Otras tecnicas

Aparte de las cinco técnicas principales, existen muchas otras, cada una con sus propias fortalezas. En general, la investigación del problema se lleva a cabo utilizando una combinación de técnicas adecuadas para la situación. Algunas otras técnicas que prevalecen en la comunidad de gestión de problemas son las pruebas cronológicas, el análisis del árbol de fallas, el método de aislamiento de fallas, las pruebas de hipótesis y el análisis del valor del dolor. Vale la pena tomarse el tiempo para aprender muchas técnicas a medida que madura el proceso de gestión de problemas de su organización.

Mejores prácticas de gestión de problemas de TI

Mejores prácticas clave de gestión de problemas

Aunque hemos discutido el proceso y los diversos métodos para practicar la gestión de problemas, hay ciertas cosas que se deben tener en cuenta al abordarlo. Lo que debe y no debe hacer lo ayudará a evitar pequeños contratiempos en su viaje de gestión de problemas.

HACER:

  • Broadcast las diferencias exactas entre un incidente y un problema : ITIL ® procesos funcionan sólo cuando hay una clara división reconocido, entre la gestión de incidentes y problemas, por lo que desarrollan una distinción que funcione para su organización.
  • Reconozca que el administrador de problemas es una función no técnica : el administrador de problemas es el pegamento que mantiene unido a todo el equipo. La parte técnica del proceso será realizada por expertos, pero el administrador de problemas permite que suceda.
  • Establezca los objetivos para sus esfuerzos de manejo de problemas : avance con metas a corto y largo plazo para que su enfoque no se vea disminuido fácilmente. Por ejemplo, considere las metas a corto plazo como algo así como resolver los diez problemas principales que interrumpen el negocio, y las metas a largo plazo similares a mejorar sus ahorros de costos de soporte.
  • Busque siempre soluciones permanentes en lugar de temporales : obtenga los verdaderos beneficios de la gestión de problemas al buscar siempre soluciones permanentes, incluso si se trata de una solución permanente.
  • Dé la bienvenida a las personas que desafían el estado de las cosas : aprecie a los miembros que cuestionan el estado actual de las cosas. Esta podría ser la chispa que lleve a mejorar positivamente el sistema de su organización.

NO HACER:

  • Intente alcanzar la perfección desde el principio : la gestión de problemas es una experiencia de aprendizaje y es única para cada organización. Tratar de ser perfecto desde el principio es prepararse para el fracaso. Nadie se convierte en una estrella de rock el primer día que empieza a tocar la guitarra.
  • Complicarse con enfoques reactivos y proactivos : tómelo con calma al principio. Algunos problemas no pueden pasarse por alto debido a su gravedad y otros deben detectarse mediante análisis.
  • Gestión de problemas medida como un proceso individual : ITIL ® procesos en su conjunto están diseñados para cooperar entre sí para hacer su entrega de servicios de TI más manejable. Tanto los buenos como los malos resultados de la gestión de problemas pueden derivarse de la gestión de incidentes, la gestión de cambios o incluso la gestión de proyectos.

Experimente cómo la gestión de problemas beneficia a su organización

Indicadores clave de rendimiento de la gestión de problemas de TI

Los indicadores clave de rendimiento (KPI) deben proporcionar valor a los usuarios, técnicos y partes interesadas por igual. Si bien estas métricas actúan como una herramienta de autoexamen, es aconsejable limitar las métricas a siete u ocho para el proceso de gestión de problemas, ya que demasiadas podrían proporcionar una percepción sesgada del proceso en sí. Puede haber problemas en el nivel del suelo, pero las diversas métricas que actúan juntas pueden llegar a una conclusión diferente.

Los KPI pueden variar según la forma en que funciona una organización, por lo que no hay una lista única de métricas aplicables para todas las organizaciones. Para determinar qué KPI deben monitorearse, se debe pedir a las partes interesadas que opinen y decidan qué sería beneficioso.

A continuación se muestran los KPI más aplicables para el proceso de gestión de problemas.

KPI Fórmula Comentario
Tiempo medio para iniciar RCA El tiempo promedio que se tarda desde la identificación de un problema hasta el inicio de la RCA. Esto muestra la eficiencia del equipo de diagnóstico de problemas.
Tiempo medio para iniciar RCA El tiempo promedio que se tarda desde la identificación de un problema hasta el inicio de la RCA.
Número total de problemas sin completar El recuento de problemas que aún no se han sometido a RCA. Esto es diferente a un problema no resuelto. Los problemas incompletos se registran, pero aún no se ha comenzado a trabajar en ellos.
Aumento / disminución porcentual de incidentes importantes Aumento / disminución porcentual de incidentes importantes Esta métrica puede ayudar a encontrar tendencias, como la frecuencia de aparición de problemas.
Número total de registros de problemas notificados El número total de problemas registrados por incidentes. A medida que su práctica de gestión de problemas madura, los problemas informados de incidentes deberían disminuir.
Tiempo medio de resolución de problemas El tiempo medio que se tarda desde la identificación hasta la resolución de un problema. Los problemas pueden tardar mucho en resolverse. Para acelerar el proceso, ayuda a medir los esfuerzos de mejora en RCA y el proceso real de gestión de problemas.
Número total de errores conocidos El recuento de errores conocidos en la KEDB. Esto destaca los esfuerzos de documentación de su organización. Si la proporción entre el número de problemas registrados y los errores conocidos es baja, es una buena señal.
Número total de problemas no resueltos El recuento de problemas no resueltos en la mesa de servicio. Los problemas no resueltos son aquellos con RCA en curso.
Número total / promedio de incidentes asociados con problemas El recuento de todos los incidentes con un ticket de problema asociado. Cuando intente ampliar sus actividades de diagnóstico proactivo, asegúrese de que esta métrica retroceda gradualmente al mínimo.
Porcentaje de problemas con una causa raíz identificada El número de problemas que tienen una causa raíz clara e identificada, en comparación con los problemas registrados en general. Ambas métricas complementan otras métricas, como la eficacia de la práctica de gestión de problemas, y ayudan con la toma de decisiones, como las decisiones monetarias.
Porcentaje de problemas con una solución alternativa El número de problemas que tienen una solución alternativa en lugar de una solución permanente, en relación con los problemas registrados en general.

Las mejores funciones para el software de gestión de problemas

Es más fácil para las organizaciones aprovechar el software para formular su proceso de gestión de problemas en lugar de intentar desarrollarlo desde cero. Existen numerosas soluciones en el mercado que afirman ser las mejores para la gestión de problemas; como mínimo, el software de gestión de problemas debe incluir las capacidades que se enumeran a continuación.

Lista de características Valor
Creación y registro de problemas Crear problemas a partir de un incidente Identifique los incidentes de un problema subyacente que requieran una investigación completa y asocie los cambios.
Marcar un problema como error conocido Mantener una KEDB.
Crea plantillas de problemas Estandarice el formato para definir problemas.
Análisis del problema Roles problemáticos y técnico Identifique al propietario del problema.
Incluya análisis, impacto y RCA para cada problema Analice el impacto, los síntomas y la causa raíz del problema y documentelos.
Marque los servicios afectados y los activos involucrados Defina con precisión cada problema y cuantifique el impacto comercial.
Solución del problema Agregar tareas con dependencias dentro de un problema Asignar la implementación de la solución a técnicos específicos con fechas de vencimiento.
Marcar soluciones provisionales como soluciones Proporcione una solución temporal con una solución alternativa o una solución permanente al problema.
Asociar un cambio con el problema Haga que la gestión de problemas funcione en conjunto con otros procesos de ITSM.
Cierre del problema Copie una solución de problema y una solución alternativa a todos los incidentes asociados Evite actividades redundantes y asegure registros consistentes en todos los tickets.
Cerrar todos los incidentes asociados automáticamente al cerrar el problema Ahorre tiempo y esfuerzo a los técnicos.
Cree registros de trabajo para registrar el costo, el esfuerzo y el tiempo necesarios para resolver un problema. Obtenga KPI detallados con respecto al costo y el tiempo necesarios para resolver problemas.
Reglas de notificación y anuncios Establezca mecanismos de notificación para mantener informadas a las partes interesadas.

Conclusión

Resolución de gestión de problemas de ITIL

ITIL ® marco de la gestión de problemas 's es una luz de guía para todas las organizaciones en el camino hacia el diagnóstico de problemas proactiva y resolución. La gestión de problemas y sus prácticas son flexibles para todas las organizaciones, independientemente del tamaño, la distribución geográfica, la industria y la tecnología que se utilizan para funcionar todos los días.

Las organizaciones con una sólida gestión de incidentes deben apuntar a una configuración básica de gestión de problemas mediante la implementación de un canal separado para registrar y gestionar problemas y mantener un KEDB. A medida que la experiencia del equipo de gestión de problemas crece junto con la organización, el proceso también debe madurar.

Para una organización que ya practica la gestión de problemas, sus aspiraciones deberían consistir en reducir los incidentes a un mínimo histórico. Esto se puede lograr más a través de un enfoque proactivo de la gestión de problemas.

Un primer paso sencillo para implementar el proceso de gestión de problemas es utilizar una herramienta de mesa de servicio con los módulos adecuados para garantizar operaciones completas de mesa de servicio de TI y control centralizado de tickets, incidentes y problemas. Tener un proceso de gestión de problemas optimizado en su organización es un proyecto a largo plazo que dará sus frutos a medida que su negocio crezca y su infraestructura de TI se amplíe.

ITIL® es una marca registrada de AXELOS Limited. IT Infrastructure Library® es una marca registrada de AXELOS Limited.