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

ITSM problem definition

Un problema es la causa o posible causa de varios incidentes. Los problemas pueden surgir por incidentes mayores que afectan a muchos usuarios, o incidentes recurrentes. Además, se pueden identificar los problemas en los sistemas de diagnóstico de infraestructura antes de que los usuarios se vean afectados.

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

La gestión de problemas de ITIL® es un procedimiento para minimizar los incidentes causados por las operaciones de infraestructura de TI al profundizar en los incidentes para determinar la causa raíz y encontrar soluciones, y también para reducir la gravedad de los incidentes al documentar los problemas existentes y proporcionar soluciones alternativas.

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 proceso de gestión de problemas de ITIL®es minimizar el impacto de los incidentes y eliminar los incidentes recurrentes. Si bien ITIL®no establece ninguna técnica específica para realizar la gestión de problemas, recomienda las siguientes tres fases:

  • ITIL problem identification

    Identificación del problema

  • ITIL problem control

    Control del problema

  • ITIL problem management error control

    Control de errores

Estas fases se discutirá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 aborda los problemas que podrían surgir como incidentes en el futuro en caso de que no se solucionen.

Un proceso de gestión de problemas fiable podría reducir significativamente la afluencia de tickets de incidentes, lo cual ahorra tiempo y esfuerzo al personal de la mesa de servicio de TI. Esta ventaja se suma a otros beneficios, como la reducción del tiempo medio para reparar (MTTR), una mayor satisfacción del cliente, una sólida base de datos de errores conocidos y un menor costo de los servicios y problemas de TI. Además, es probable que una organización que implemente la gestión proactiva de problemas encuentre un gran valor al identificar y eliminar los problemas antes de que interrumpan los procesos comerciales.

La gestión de problemas vista como una práctica de ITIL®es más útil cuando se usa con otras prácticas de ITIL®en la cadena de valor general del servicio. La información se intercambia entre las diversas prácticas de ITIL®, es decir, la gestión de incidentes, la gestión de cambios, la gestión de activos de TI la gestión del conocimiento y la mejora continua del servicio. Esta información intercambiada entre las partes acumula valor a medida que avanza a través de cada práctica de ITIL®creando a su vez un óptimo proceso de gestión de servicios de TI.

Antes de continuar, lea las siguientes definiciones que 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 la problemática subyacente del problema. El 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 cuya solución alternativa o causa raíz son conocidas.
  • Base de datos de errores conocidos (KEDB): Una base de datos creada al documentar los errores conocidos usando la gestión de incidentes y la gestión de problemas.
  • En esta guía examinaremos cada aspecto de la gestión de problemas en detalle, proporcionándole todo el conocimiento que necesita sobre cómo implementar la gestión de problemas en su empresa.

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

Major incident management vs Problem management

En ITIL®, los términos incidente y problema pueden parecer sinónimos, pero ambos se diferencian por el papel que desempeñan para lograr una excelente calidad de servicio. Es importante saber cómo interactúan entre sí la gestión de incidentes y la gestión de problemas y en qué se diferencian, especialmente dónde termina un incidente y comienza un problema.

Gestión de incidentes

Un incidente es una interrupción no planificada de un servicio completo o solo un componente de éste. Analicemos 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 emite un ticket rápidamente para aplicar una solución alternativa e imprimir los informes. Este es un incidente.

El proceso de gestión de incidentes se trata de manejar los 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 la interrupción o incidente se resuelva lo más rápido posible con una solución definitiva o una solución alternativa.

Gestión de problemas

La gestión de problemas no se trata de restaurar los servicios o resolver las problemáticas, sino de determinar y eliminar la causa. El problema se registra en una mesa de servicio cuando hay incidentes recurrentes que tienen problemáticas comunes, o si ocurre un incidente mayor que afecta a muchos usuarios. En nuestro escenario, no funciona la única impresora en el departamento y todos los usuarios en ese departamento se vieron afectados, lo cual fue registrado como un problema por el personal de la mesa de servicio para encontrar la causa y la solución. Se puede cerrar un incidente cuando se proporciona una solución alternativa, pero se registra un problema para arreglar la impresora de forma permanente, de modo que no vuelva a ocurrir esta problemática.

Volviendo a nuestro escenario, la problemática de la impresora se someterá a un RCA para encontrar una solución permanente, y se supervisará como un ticket de problema mientras el negocio continúa funcionando con la solución alternativa en su lugar. Si el equipo de gestión de problemas no puede encontrar una solución definitiva, se documenta la solución alternativa y se agrega la problemática en la KEDB. De esta manera, la gestión de problemas no solo consiste en eliminar los incidentes al encontrar la causa raíz subyacente, sino también en determinar la solución más factible que se pueda 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 entre sí y están estrechamente alineadas. La gestión de incidentes garantiza la continuidad en las operaciones comerciales, mientras que la gestión de problemas se ocupa de los problemas y problemáticas subyacentes.

Gestión de problemas reactiva vs. gestión de problemas proactiva

Reactive vs proactive problem management

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

La gestión de problemas reactiva reacciona a los incidentes que surgen y luego continúa con el proceso de gestión de problemas. Básicamente, el enfoque reactivo para la gestión de problemas tiene como objetivo encontrar y eliminar las causas raíz de los errores conocidos y únicamente trata el problema si aparece como incidentes mayores o recurrentes.

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

La gestión de problemas proactiva busca las problemáticas, las fallas y los errores conocidos en los sistemas de TI con base en los incidentes pasados, los logs de datos del monitor de red y otras fuentes de información, luego procede a resolverlos permanentemente antes de que surjan como incidentes. Este proceso hace parte de la mejora continua del servicio. La gestión de problemas proactiva también tiene como objetivo resolver todos los errores conocidos de la KEDB si es posible hacerlo.

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

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

how to implement reactive and proactive problem management

Las organizaciones que apenas están comenzando a usar la gestión de problemas deben centrar sus esfuerzos en implementar un proceso de gestión de problemas reactivo. Es conveniente utilizar el personal existente de la mesa de servicio que tiene experiencia en la resolución de problemas cuando no están ocupados con incidentes diarios. Al hacerlo, obtienen una valiosa experiencia antes de implementar una gestión de problemas proactiva.

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

Sin embargo, muchas organizaciones no se someten a esta transición, ya que es difícil cuantificar los beneficios de la gestión de problemas proactiva, que podría percibirse como una resolución de problemas potenciales y no reales. Sin embargo, algunas de las organizaciones más efectivas del mundo practican la gestión de problemas proactiva y encuentran enormes beneficios en ello.

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

ITIL benefits problem management

Hay algunos obstáculos que las organizaciones pueden enfrentar en el proceso de establecer la gestión de problemas. Es posible que la organización no tenga los recursos para asignar a un equipo de gestión de problemas, o que ya tenga una forma poco ortodoxa de gestionar los problemas y sea reacia al cambio. A veces, podría tratarse de una denegación de solicitud relacionada con los costos.

Por consiguiente, es importante incluir a todos los interesados en el proceso de gestión de problemas y explicar cómo proporciona valor a las diferentes facetas de la organización. Estos beneficios incluyen:

  • Elimina las fallas en los servicios de una organización a través de una documentación adecuada.
  • Mejora el diseño del servicio al identificar y resolver los puntos débiles, garantizando la ruta más efectiva y eficiente para la entrega del servicio.
  • Aumenta la tasa de corrección a la primera vez en las fallas del servicio al proporcionar soluciones permanentes para los incidentes en lugar de limitarse a las soluciones alternativas.
  • Disminuye el impacto de los incidentes que afectan a varios usuarios o a un solo usuario en un momento crucial.
  • Previene la mayoría de los incidentes y problemas que afectan a una organización con el tiempo, lo que aumenta la productividad del usuario.
  • Fortalece la confianza que los usuarios tienen en los servicios de TI de la organización.
  • Disminuye el tiempo que lleva recuperarse de los fallos a través del mantenimiento sistemático de una KEDB.
  • Previene los incidentes recurrentes a través de correcciones únicas, ahorrando valiosos esfuerzos a la mesa de servicio para su resolución.
  • Fomenta la maduración de los servicios de TI ya que la organización se desarrolla aprendiendo de los problemas resueltos.
  • Desarrolla el talento de TI dentro de la organización a través de la concienciación técnica y conocimientos valiosos.

Emprenda su viaje hacia la gestión de problemas

Roles y responsabilidades de la gestión de problemas de TI

Problem management responsibilities

Los roles de un equipo de gestión de problemas están directamente relacionados con la estructura organizativa existente. 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 las pequeñas empresas de TI, las responsabilidades del equipo pueden estar combinadas, o en el caso de las grandes empresas multinacionales, pueden estar especializadas.

De cualquier manera, depende de la conveniencia y flexibilidad del equipo de TI diseñar un entorno que garantice que los problemas se aborden de manera eficiente en términos de las recomendaciones de ITIL®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 ser precavido con los recursos que la organización puede asignar 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 cuanto a la rendición de cuentas durante la prestación del servicio.

A continuación se enumeran los roles y responsabilidades generales de los equipos de gestión de problemas.

Rol Responsabilidad
Gestor 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 cualquier ticket de problema que se le asigne.
Agente del problema Responsable de las tareas asociadas al ticket de problema.
Equipo de diagnóstico Un grupo de personas con diversos conocimientos, responsables del RCA de un problema.

Flujo del proceso de gestión de problemas de TI

Al igual que una organización crea valor para sus clientes, la gestió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 implementa una mesa de servicio lista para ITIL® el flujo simplificado del proceso de problema se ve así:

ITIL Problem management process flow steps

Según ITIL®, puede implementar procesos de gestión de problemas con cualquier tecnología que considere adecuada para su organización. La tecnología implementada debe tener funcionalidades que permitan establecer las tres fases de la gestión de problemas de ITIL®

Las tres fases son:

Phases of problem management
Problem identification definition

Identificación del problema

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

Mientras que el personal de la mesa de servicio normalmente reportaría los problemas después de recibir una oleada de incidentes, un enfoque proactivo para la gestión de problemas identifica los problemas:

  • Analizando las tendencias de incidentes, aprovechando los sistemas de monitoreo de red y utilizando otro software de diagnóstico.
  • Detectando los riesgos de los incidentes que podrían repetirse.
  • Evaluando la información recibida de socios y proveedores.
  • Evaluando la información de los desarrolladores de software, ingenieros y equipos de prueba internos.

Dependiendo de la estructura, el dominio y la cultura de su organización, incluso podría haber otros métodos para identificar los problemas. Sin embargo, es importante contar con un sistema para que los problemas se reporten, identifiquen, prioricen y registren para su posterior investigación y diagnóstico.

Problem control in ITIL

Control del problema

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

El control del problema incluye actividades como la priorización, la investigación, el análisis y la documentación de errores conocidos y soluciones alternativas. Existen numerosas técnicas que ayudan en la priorización y el análisis de problemas. Una buena regla general es abordar primero los problemas que, una vez solucionados, reducen significativamente la interrupción de los servicios en la organización.

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

Las soluciones alternativas se documentan en los registros de problemas. En general, si un problema persiste por más tiempo, es aconsejable implementar una solución alternativa rápida. Esta solución alternativa incluso puede ser 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 alternativa y perfeccionar la resolución si es necesario. Como puede ver, una solución alternativa efectiva para los incidentes puede convertirse en una solución permanente para algunos problemas.

Problem control and error control

Control de errores

Esta fase gestiona los errores conocidos de la KEDB al revisar periódicamente las posibles soluciones permanentes si pasan el análisis de costo-beneficio.

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

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

Un sistema integrado que implementa las mejores prácticas de prestación de servicios mejora los servicios empresariales y las capacidades de los servicios de TI. Un proceso de gestión de problemas eficiente interactúa con otros procesos de ITI®

Incident management vs problem management vs change management

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

Gestión de incidentes

La gestión de incidentes es el proceso metódico que consiste en registrar, categorizar, priorizar, asignar y resolver las problemáticas 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 implementa una solución alternativa en lugar de una solución permanente. Cada actividad en esta práctica se documenta detalladamente y se envía al equipo de gestión de problemas, que inicia el RCA para desarrollar una solución permanente. Puede ver que a pesar de que la gestión de problemas es su propio proceso, depende de un proceso robusto de gestión de incidentes.

Gestión de cambios

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

De acuerdo con el marco de ITIL®la responsabilidad de la gestión de problemas concluye al determinar la causa raíz que conduce a la solución de un problema y, de hecho, la solución se implementa con el control de cambios. Dado que implementar un cambio implica gestionar el riesgo en varias unidades de negocio, requiere de un proceso separado para garantizar 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 que la solución del problema y el cambio implementado asociado sean coherentes.

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 derivar el valor máximo de los activos, controlar los costos de los activos y gestionar 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 se pueden cruzar cuando surgen problemas con los activos de hardware y software utilizados por la organización. Cuando la causa raíz de un problema parece estar relacionada con un producto o servicio, el registro detallado del inventario de la gestión de activos de TI agiliza el proceso de resolución de problemas. Además 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 del RCA.

ITIL problem resolution

Pongamos las cosas en perspectiva con un escenario.

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

El equipo de gestión de problemas proactiva de Zylker decide realizar un análisis de tendencia de los incidentes ocurridos en los últimos seis meses. Encuentran varios 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 recopilados de todos los incidentes documentados.

El técnico en Nueva Delhi ve que el servidor SQL está utilizando diferentes tipos de protocolos, incluidos iSCSI y el protocolo de canal de fibra, para vincular las instalaciones de almacenamiento de datos. Dado que ambos protocolos funcionan en una red Ethernet, hay dudas sobre si configuró el switch de bloque local para funcionar con la transferencia de datos de paquetes grandes. El técnico recibe datos del equipo de gestión de activos de TI y concluye que el switch no fue el causante. Esto se comprueba con la evidencia que demuestra que no había problemas para generar informes localmente.

Lo siguiente es analizar la red de área amplia (WAN), ya que un gerente de Mumbai tiene problemas para generar el informe mensual. El técnico, debido a su experiencia en problemas de red, tiene dudas sobre el flujo de tráfico al final de cada mes, por lo que instala un software en los routers y switches de la compañía para analizar el tráfico que pasa a través de ellos y agregar los datos estadísticamente.

El software genera gráficos y diagramas que muestran los principales protocolos que se utilizaron, junto con el ancho de banda que cada protocolo consumió durante un mes. Esto revela un uso del ancho de banda significativamente alto al final del mes aproximadamente al mismo tiempo que se genera el informe mensual. Después de realizar un examen detallado, se descubre que las copias de seguridad de la imagen completa del sistema se programaron aproximadamente al mismo tiempo que el informe mensual y esto causó un cuello de botella en la WAN.

Ahora que se identificó la causa raíz del problema, el técnico emite un ticket de cambio para reprogramar la copia de seguridad de la imagen a las primeras horas de la mañana fuera del horario comercial, lo cual nivelará el tráfico en la red.

Este es un resumen general de los pasos realizados en este escenario:

Actividad Practica involucrada
El gerente en Mumbai tuvo problemas para generar los informes mensuales desde el servidor SQL en Nueva Delhi. Se reportó el incidente y los informes se generaron localmente y luego se enviaron al gerente. Se cerró el ticket. Gestión de incidentes
El equipo de gestión de problemas proactiva realizó un análisis de tendencias de los incidentes ocurridos en los últimos seis meses. Se encontraron varios incidentes relacionados con el servidor en Nueva Delhi. Gestión de problemas, gestión de incidentes
El técnico de Nueva Delhi examinó la red y el protocolo del servidor SQL, y no estaba seguro de si el switch de bloque local estaba configurado o no para funcionar con la transferencia de datos de paquetes grandes. Gestión de problemas, gestión de activos de TI
El técnico recibió datos del equipo de gestión de activos de TI y concluyó que el switch no era el causante. 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ó un software en los routers y switches para analizar el tráfico y agregar los datos estadísticamente. Gestión de problemas, gestión de activos de TI
Después de realizar un examen detallado, se descubrió que las copias de seguridad de la imagen completa del sistema se programaron aproximadamente al mismo tiempo que la generación del informe y esto causó un cuello de botella en la WAN. Gestión de problemas
El técnico emitió un ticket de cambio para reprogramar la copia de seguridad de la imagen a las primeras horas de la mañana fuera del horario comercial. Gestión de problemas, gestión de cambios

Todas las prácticas de ITIL® tienen una relación intrincada con otras prácticas de ITIL®. A medida que su 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 garantizar una prestación de servicios adecuada y orientada a los negocios.

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

El proceso de gestión de problemas se puede establecer 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 estrictas.

Dado que los problemas pueden tener cualquier forma o tamaño, es imposible apegarse a una sola técnica para encontrar todas las soluciones; se obtendrán mejores resultados si se combinan varias técnicas. Un simple problema de conectividad LAN podría resolverse con una sesión rápida de lluvia de ideas, pero un problema de red o VoIP podría necesitar un análisis más profundo.

Estas son algunas técnicas que puede aplicar en el proceso de gestión de problemas de su organización.

ITIL problem solving techniques

Lluvia de ideas

Al conversar con varios departamentos, puede obtener 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 se encarga de lo siguiente:

  • Dirigir la reunión
  • Documentar la información obtenida
  • Destacar las medidas que se van a tomar
  • Dar seguimiento al entregable discutido
  • Evitar que la sesión se prolongue demasiado

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 porqués. Estas técnicas se discutirán más adelante en esta sección.

Proactive problem management methods

Método Kepner-Tregoe

El método Kepner-Tregoe (K-T) 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 tanto en la gestión de problemas proactiva como reactiva.

El método sigue cuatro procesos:

  • Evaluación de la situación: Evaluar y aclarar el escenario
  • Análisis del problema: Relacionar la causa con el efecto
  • Análisis de decisiones: Sopesar las opciones alternativas
  • Análisis de problemas potenciales: Anticipar el futuro

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

Definir 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, definir el problema de manera exhaustiva elimina las nociones preconcebidas que podría tener algún participante, lo cual ahorra mucho 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

Esta definición de hecho describe la situación inusual, pero requiere de 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 se puede modificar de la siguiente manera:

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

Esta definición proporciona más claridad y evita que los empleados formulen preguntas redundantes. Sin embargo, esta definición puede mejorarse aún más. Imagine que la causa de la falla de la copia de seguridad de 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, modifique la definición de la siguiente manera:

La copia de seguridad de datos del 15 de noviembre falló en el servidor #34-C después de que el ingeniero Noah aplicara el parche 3.124

Esta definición detallada evita las 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 tiempo y esfuerzo valiosos, proporcionan un sentido lógico de dirección para el análisis y eliminan cualquier noción preconcebida sobre el problema.

Describir el problema

El siguiente paso es establecer una descripción detallada del problema. El método K-T proporciona las preguntas que se deben formular sobre cualquier problema para ayudar a identificar las posibles causas.

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

  • ¿Cuál es el problema?
  • ¿Dónde ocurrió el problema?
  • ¿Cuándo ocurrió el problema?
  • ¿Cuál es el alcance del problema?

Cada una de estas preguntas exige dos tipos de respuestas:

ES: Como en "¿Cuál es el problema?" o "¿Dónde ocurrió el problema?"

y

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

Este ejercicio ayuda a comparar y resaltar el qué, dónde, cuándo y cómo de la desviación que está ocurriendo en el rendimiento normal de los procesos comerciales.

Establecer las posibles causas

La comparación entre el rendimiento normal y el rendimiento anormal del paso anterior ayuda a crear una lista de 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 #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 Nuevo procedimiento de parche seguido
Dónde Servidor del cuarto piso Servidores del sótano Normalmente lo realizan los ingenieros de nivel 3 El ingeniero de nivel 1 lo aplicó
Cuándo 15 de noviembre, 12:32 am En otro momento Ninguno identificado
Alcance Solo en el servidor #34-C Cualquier otro servidor Ninguno identificado

Las nuevas causas posibles se hacen evidentes cuando la información se analiza en conjunto. Para nuestro problema de ejemplo, la causa raíz se puede reducir a:

Error de procedimiento causado por la transferencia de conocimiento inadecuada por parte de los ingenieros de Nivel 3.

Cualquiera que sea el problema, se puede realizar un análisis detallado de las posibles causas con base en la comparación relevante.

Probar la causa más probable

El penúltimo paso es hacer una pequeña lista de las causas probables y someterlas a prueba antes de sacar una conclusión. Cada causa probable se debe probar con esta pregunta:

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

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

Posible causa raíz Cierto si ¿Posible causa raíz?
El servidor # 34-C tiene un problema Solo el servidor # 34-C ha sido afectado Tal vez
Procedimiento incorrecto El mismo procedimiento afecta a otro servidor Probablemente
Error del ingeniero El problema no volvió a ocurrir con el mismo procedimiento Probablemente no

Comprobar la verdadera causa

El último paso es eliminar todas las causas improbables y buscar evidencia para las causas más probables. Con esta verificación, es hora de proponer una solución al problema. Si no hay evidencia de la posible causa raíz, no se debe intentar implementar la solución.

ITIL root cause analysis

Análisis de Ishikawa, o análisis de diagrama de causa y efecto

El análisis de Ishikawa utiliza el diagrama de causa y efecto (también llamado «diagrama de espina de pescado») para enumerar la causa y los efectos de un problema y se puede combinar con las sesiones de lluvia de ideas y el método de los cinco porqués. Que no lo engañe la simplicidad del diagrama de Ishikawa al realizar un RCA, ya que resulta muy útil para manejar problemas complejos.

Para comenzar el análisis, defina el problema y úselo como la «cabeza del pescado» en el diagrama. Dibuje la «columna vertebral» y agregue las categorías desde las cuales podría originarse el problema ilustrándolas como las «espinas» del diagrama de pescado.

En general, 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 que sea relevante para su problema, entorno, organización o industria.

Una vez que estas categorías formen las espinas del pescado, comience a asociar las posibles causas de cada categoría. Cada posible causa también se puede ramificar para detallar la razón de esa ocurrencia. Esto podría convertirse en un diagrama complejo con cuatro a cinco niveles de causas y efectos, que posteriormente se derivan en la causa raíz del problema.

Fishbone diagram example

Se recomienda dividir las espinas densas en espinas adicionales según sea necesario. Alternativamente, combinar las espinas vacías con otras espinas relacionadas permite ordenar y comprender mejor el diagrama. Además, debe asegurarse de que las espinas estén llenas de causas, no solo síntomas del problema.

Este análisis también es un esfuerzo de colaboración y requiere un moderador que dirija las sesiones de lluvia de ideas de manera efectiva. Todos los participantes tienen la oportunidad de participar, proporcionando una visión integral del problema.

ITIL problem classification categories

Análisis de Pareto

El principio de Pareto es una observación que sugiere 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 útil aplicar el análisis de Pareto antes de comenzar a resolver 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 la clasificación de todos los problemas. Un diagrama de Pareto es un gráfico de barras que muestra el porcentaje acumulativo de la frecuencia de varias clasificaciones de problemas.

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

  • Recopile datos de los tickets de problema de su herramienta de mesa de servicio.
  • Remodele los datos en categorías basadas en varios atributos.
  • Cree una tabla de Pareto para determinar la frecuencia de los problemas en cada clasificación durante un período de tiempo específico.
  • Calcule la frecuencia de la ocurrencia de los problemas en cada categoría.
  • Genere el porcentaje de frecuencia acumulativo en orden decreciente.
  • Grafique los datos en 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 Dentro del SLA Fuera del SLA Sin SLA
Clasificación Atributo Recuento Acumulado % de contribución
Duración Sin SLA 670 1,470 38.72%
Prioridad Alto 550 2,020 53.21%
Duración Fuera del SLA 500 2,520 66.39%
Categoría Red 430 2,950 77.71%
Prioridad Urgente 300 3,250 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 Dentro del SLA 2 3,796 100%

Este diagrama ayuda a identificar los problemas que se deben resolver 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 los problemas, mientras que los otros métodos analizan la causa raíz.

Es importante recordar que la regla 80/20 sugiere las causas probables y a veces podría equivocarse.

ITIL v4 problem management

Técnica de los cinco porqués

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

La técnica de los cinco porqués complementa muchas otras técnicas de resolución de problemas como el método Ishikawa, el análisis de Pareto y el método K-T.

Retomando el ejemplo de la falla de la copia de seguridad de los datos en un servidor, apliquemos la técnica de los cinco porqués.

¿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 la transferencia de conocimiento fue inadecuada.
¿Por qué hubo una transferencia de conocimiento inadecuada? No hay un horario o formato estandarizado en la organización.

Este proceso iterativo revela que no existe un formato estandarizado, lo que ha causado el problema de la falla de la copia de seguridad de datos.

En nuestro contexto, 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 imprescindible colaborar con las partes interesadas que tienen un conocimiento detallado del dominio en el que reside el problema.

Al adoptar partes del método K-T junto con la técnica de los cinco porqués, como proporcionar evidencia a cada respuesta antes de validarla con una pregunta de respuesta, puede garantizar la precisión del análisis durante las sesiones de resolución de problemas.

5 whys to solve problems

Otras técnicas

Además 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 se usan con frecuencia 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 de puntos débiles. 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 la gestión de problemas de TI

Problem management key best practices

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

LO QUE DEBE HACER:

  • Establecer la diferencia entre un incidente y un problema de manera precisa: Los procesos de ITIL®solo funcionan si existe una distinción clara y reconocida entre la gestión de incidentes y la gestión de problemas. Por lo tanto, debe establecer una distinción que funcione para su organización
  • Reconocer que el gestor de problemas es un rol no técnico: El gestor de problemas es el pegamento que mantiene unido a todo el equipo. La parte técnica del proceso será realizada por expertos, pero el gestor de problemas es quien permite que esto suceda.
  • Establecer los objetivos para sus esfuerzos de gestión de problemas: Avance con objetivos a corto y largo plazo para que su enfoque no se vea afectado fácilmente. Por ejemplo, considere que los objetivos a corto plazo son algo así como resolver los diez problemas principales que afectan el negocio, y los objetivos a largo plazo son reducir los gastos de soporte.
  • Siempre buscar soluciones permanentes en lugar de soluciones temporales: Aproveche los verdaderos beneficios de la gestión de problemas buscando soluciones permanentes, incluso si se trata de una solución alternativa permanente.
  • Valorar 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 justo lo que necesita para mejorar el sistema de su organización.

LO QUE NO DEBE HACER:

  • Intentar lograr la perfección desde el principioLa gestión de problemas es una experiencia de aprendizaje y es única para cada organización. Intentar ser perfecto desde el principio es prepararse para el fracaso. Nadie se convierte en una estrella de rock el primer día que comienzan a tocar la guitarra.
  • Complicarse con enfoques reactivos y proactivos: Tómelo con calma al principio. Algunos problemas no se pueden pasar por alto debido a su gravedad y otros se deben encontrar a través del análisis.
  • Mida la gestión de problemas como un proceso individual: Los procesos de ITIL® están diseñados para cooperar entre sí y facilitar el manejo de la prestación de servicios de TI. Tanto los buenos como los malos resultados de su 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 para la gestión de problemas de TI

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

Los KPI pueden variar según la forma en que funciona una organización, por lo que no hay una sola lista de métricas aplicables para todas las organizaciones. Para determinar cuáles KPI se deben monitorear, se debe pedir a los interesados que evalúen y decidan qué sería mejor.

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

KPI Fórmula Comentario
Tiempo promedio para iniciar el RCA El tiempo promedio desde la identificación de un problema hasta el inicio del RCA. Esto muestra la eficiencia del equipo de diagnóstico de problemas.
Tiempo promedio para iniciar el RCA El tiempo promedio desde la identificación de un problema hasta el inicio del RCA.
Número total de problemas incompletos El recuento de problemas que aún no se han sometido al RCA. Esto difiere de un problema no resuelto. Los problemas incompletos se registran, pero aún no se ha comenzado a trabajar en ellos.
Porcentaje de aumento / disminución de incidentes mayores Porcentaje de aumento / disminución de incidentes mayores Esta métrica puede ayudar a identificar tendencias, como la frecuencia de ocurrencia de los problemas.
Número total de registros de problemas reportados El número total de problemas registrados a partir de incidentes. A medida que madura su práctica de gestión de problemas, deberían disminuir los problemas reportados a partir de incidentes.
Tiempo promedio de resolución de problemas El tiempo promedio transcurrido desde la identificación hasta la resolución de un problema. Los problemas pueden tardar mucho tiempo en resolverse. Para acelerar el proceso, se recomienda medir los esfuerzos de mejora en el RCA y el proceso de gestión de problemas.
Número total de errores conocidos El recuento de errores conocidos en la KEDB. Esto resalta los esfuerzos de documentación de su organización. Si la relación entre el número de problemas registrados y los errores conocidos es baja, es una buena señal.
Número total de problemas sin resolver El recuento de problemas no resueltos en la mesa de servicio. Los problemas no resueltos son aquellos cuyo RCA está 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 se disminuya 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 efectividad 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 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

Para las organizaciones es mucho más fácil aprovechar el software para formular su proceso de gestión de problemas en lugar de tratar de 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 siguientes funciones.

Lista de funciones Valor
Creación y registro del problema Crear problemas a partir de un incidente Identificar incidentes de un problema subyacente que requieren una investigación exhaustiva y asociar cambios.
Macar un problema como un error conocido Mantener una KEDB.
Crear plantillas de problemas Estandarizar el formato para la definición de problemas.
Análisis del problema Roles para los problemas y técnicos Identificar el propietario del problema.
Incluir análisis, impacto y RCA para cada problema Analizar el impacto, los síntomas y la causa raíz del problema, y documentarlos.
Marcar los servicios afectados y activos involucrados Definir con precisión cada problema y cuantificar el impacto en el negocio.
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 las soluciones alternativas como soluciones Proporcionar una solución temporal con una solución alternativa o permanente para el problema.
Asociar un cambio con el problema Hacer que la gestión de problemas funcione junto con otros procesos de ITSM.
Cierre del problema Copie la solución del problema y la solución alternativa a todos los incidentes asociados Evitar actividades redundantes y garantizar registros consistentes en todos los tickets.
Cerrar todos los incidentes asociados automáticamente al cerrar el problema Ahorrar tiempo y esfuerzo a los técnicos.
Crear registros de trabajo para registrar el costo, el esfuerzo y el tiempo necesario para resolver el problema Obtener KPI detallados con respecto al costo y el tiempo necesario para resolver los problemas.
Reglas de notificación y anuncios Establecer mecanismos de notificación para mantener informados a los interesados.

Conclusión

ITIL Problem management resolution

El marco de gestión de problemas de ITIL®es una guía para todas las organizaciones encaminadas hacia un enfoque proactivo para el diagnóstico y la resolución de problemas. La gestión de problemas y sus prácticas se adaptan a todas las organizaciones, independientemente del tamaño, la distribución geográfica, la industria y la tecnología utilizada para funcionar todos los días.

Las organizaciones con una gestión de incidentes robusta deben aspirar a establecer un entorno básico de gestión de problemas mediante la implementación de un canal separado para registrar y gestionar problemas y mantener una 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 fácilmente a través de un enfoque proactivo para la gestión de problemas.

Para implementar el proceso de gestión de problemas, un primer paso consiste en utilizar una herramienta de mesa de servicio con los módulos correctos para garantizar la integridad de las operaciones de la mesa de servicio de TI y un control centralizado para los tickets, incidentes y problemas. Optimizar el proceso de gestión de problemas en su organización es un proyecto a largo plazo que dará sus frutos a medida que crezca su negocio y su infraestructura de TI.

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

Alinee su entorno de TI con las mejores prácticas de la industria

A través de la experiencia en gestión de problemas, puede implementar otras disciplinas de ITSM con más confianza y aprender a fortalecer la prestación de servicios acorde a ITIL. Descargue una copia gratuita de nuestro manual d ITIL y una lista de verificación de mejores prácticas para revisar su solución de gestión de problemas.

  • Problem management sofware feature checklist

    Lista de verificación de funciones para la gestión de problemas

  • major incident procedure ITIL

    Manual de héroes de ITIL

Al hacer clic en 'Obtener kit de recursos de ITSM', usted acepta que sus datos personales sean procesados de acuerdo con la Política de Privacidad.