Gestión de Problemas

42 decisiones que mejoran la calidad del servicio prestado y disminuyen el volumen general de incidentes informados. La gestión de incidentes es solo un proceso en el marco de operación de servicio.

43 como "error conocido". Estos se documentan en la base de datos de KEDB, la que puede ser la misa de la base de datos física y la de los datos del problema.

Una vez que se haya identificado el error conocido, el siguiente paso es determinar cómo solucionarlo. Por lo general, esto implicará un cambio en uno o más CI, por lo que el resultado del proceso de gestión de problemas sería una solicitud de cambio, que luego se evaluaría mediante el proceso de gestión de cambios o se incluiría en el registro CSI.

La gestión de problemas se considera un proceso reactivo en el sentido de que se invoca después de que se hayan producido los incidentes, pero en realidad es proactivo, ya que su objetivo es garantizar que los incidentes no se repitan en el futuro, o si lo hacen, para minimizar su impacto.

2.2.3.1. Manejo de Problemas 101

La gestión de problemas es un paso más allá de la gestión de incidentes en el ciclo de vida de la operación del servicio ITIL. La administración de incidentes maneja cualquier interrupción no planificada o la reducción de la calidad de un servicio de TI, mientras que la administración de problemas maneja las causas de los incidentes. O en términos más claros, la administración de incidentes restaura el servicio mientras que la administración de problemas elimina la causa de los servicios fallidos.

ITIL define un problema como la causa de uno o más incidentes.

Algunos incidentes, como un mal funcionamiento del mouse en la estación de trabajo de un usuario, no son indicativos de un problema. Otros incidentes, como las repetidas interrupciones de la red, crean una investigación del problema debido a su frecuencia. En este caso, la gestión de problemas es reactiva. La gestión proactiva de problemas implica abordar el estado del hardware, el software y los procesos, y abordar de manera preventiva los problemas antes de que causen incidentes excesivos. Ni la gestión de incidentes ni la gestión de solicitudes tienen la capacidad de ser proactivos como la gestión de problemas.

44 2.2.3.2. Propósito:

Cuando los usuarios continúan enfrentando los mismos incidentes sin resolución, pierden la confianza en la capacidad de la mesa de servicio para resolver cualquier problema. Por lo tanto, el objetivo principal de la administración de problemas es identificar, solucionar problemas, documentar y resolver las causas raíz de los incidentes repetidos. La información sobre incidentes se filtra hasta la gestión de problemas y la gestión de problemas, a su vez, proporciona al servicio de atención al cliente el error conocido y la información de solución necesaria para mitigar los problemas a corto plazo.

Los problemas incluyen problemas como la falla del hardware o una consulta de base de datos configurada de forma inadecuada.

La gestión de problemas reduce los incidentes a largo plazo. La reducción de incidentes disminuye la carga en la mesa de servicio, mejora la satisfacción del usuario final y disminuye los costos a largo plazo asociados con el tiempo de inactividad del usuario y del servicio. Cuando no se pueden resolver los problemas, la administración de problemas trabaja con el servicio de atención al cliente para mitigar el impacto de los incidentes relacionados. El objetivo final de la gestión de problemas siempre debe ser reducir la cantidad global de incidentes prevenibles y, por lo tanto, aumentar la calidad del servicio prestado.

2.2.3.3. Alcance

La gestión de problemas tiene un alcance muy limitado e incluye las siguientes actividades:

• Actividad referida a la detección de problemas

• Actividad referida al registro de problemas

• Actividad referida a la categorización de problemas

• Actividad referida a la prioridad

• Actividad referida a la indagación y diagnóstico.

• Actividad referida a la creación de un registro de error conocido

• Actividad referida a la resolución de problemas y cierre.

• Actividad referida a la revisión del problema mayor

45 2.2.3.4. Función Principal:

Si bien la gestión de problemas implica varias funciones, la más importante es la mesa de servicio. Si bien también se conoce como mesa de ayuda, este no es el término preferido por ITIL y debe evitarse. En ITIL, esta función actúa como el único punto de contacto para que los clientes del servicio informen incidentes y envíen solicitudes de servicio. Sin un solo punto de contacto, los usuarios pueden contactar al personal y esperar un servicio inmediato sin limitaciones de priorización. Desafortunadamente, esto significa que los incidentes urgentes pueden ignorarse mientras que los incidentes que no afectan el negocio se manejan primero. Otro escenario común es que los incidentes importantes, pero de baja prioridad no se manejan durante semanas, mientras que el personal de soporte de TI se encarga de los problemas más urgentes en sus escritorios, sin dejar tiempo para los problemas más pequeños. La mesa de servicio le permite al proveedor del servicio abordar los problemas de todos de manera rápida y secuencial. También fomenta la transferencia de conocimiento entre departamentos.

Esta función se puede dividir en niveles de soporte separados llamados niveles. El primer nivel es para cuestiones básicas. Esto incluye problemas de baja prioridad, como la solución de problemas básicos de la computadora. Los incidentes de nivel uno son los que tienen más probabilidades de convertirse en modelos de incidentes, ya que son fáciles de resolver y se repiten con frecuencia. Los incidentes de nivel “uno” no afectan el negocio u otros usuarios. Siempre se pueden solucionar hasta que la mesa de servicio los resuelva. Por ejemplo, un Microsoft ® de Outlook ® de error se puede evitar mediante el uso de la aplicación de correo electrónico basado en la web en su lugar.

Luego está el nivel dos. El nivel de soporte de segundo nivel maneja los problemas que tienen algún impacto en el usuario, pero no en el negocio en general. Por lo general, estos incidentes requieren más habilidad o acceso para resolverlos. Los incidentes

46 de nivel dos son de prioridad media, y requieren una respuesta más inmediata y un mayor nivel de acceso o capacitación que los incidentes de nivel uno.

Los incidentes de nivel tres afectan a toda la organización y a muchos usuarios. A veces, un VIP puede caer en una categorización de nivel dos o tres para proporcionar un tiempo de respuesta más rápido para estos usuarios. A menudo, estos incidentes caen en el proceso de Respuesta a Incidentes Mayores (MIR). ITIL define estos incidentes como aquellos que causan una interrupción significativa en el negocio. Estos son siempre de alta prioridad. Los incidentes que requieren MIR son buenos candidatos como posibles problemas, ya que afectan el negocio y probablemente tienen una causa raíz diferente a los incidentes regulares.

Sabrá que ha evaluado con precisión los niveles y las prioridades cuando la mayoría de los incidentes se encuentran en el nivel uno / baja prioridad, menos en el nivel dos, y solo unos pocos requieren una escalada al nivel tres.

La mesa de servicio interactúa con el equipo de gestión de problemas de varias maneras. La primera interacción es cuando se plantea un problema potencial. Esto sucede a menudo cuando un incidente se considera no resuelto en la mesa de servicio y se debe escalar. Esto también sucede cuando ocurre un incidente repetidamente a pesar de los pasos normales de resolución de problemas y resolución. Finalmente, cuando el equipo de administración de problemas o mejora continua del servicio identifica los problemas de manera proactiva, puede comunicarse con el servicio de atención al cliente para obtener más información o estadísticas de incidentes.

2.2.3.5. Proceso

El proceso de gestión de problemas de ITIL tiene muchos pasos, y cada uno es de vital importancia para el éxito del proceso y la calidad del servicio prestado.

El primer paso es detectar el problema. Se plantea un problema a través de la escalación desde la mesa de servicio, o a través de

47 la evaluación proactiva de los patrones de incidentes y las alertas de la gestión de eventos o los procesos de mejora continua del servicio. Los signos de un problema incluyen incidentes que ocurren en toda la organización con condiciones similares, incidentes que se repiten a pesar de la resolución exitosa de problemas, e incidentes que no se pueden resolver en la mesa de servicio.

El segundo paso es registrar el problema. En un marco ITIL, los problemas se registran en un registro de problemas. Un registro de problemas es una compilación de cada problema en una organización. Esto se puede lograr a través de un sistema de tickets que permite tipos de tickets problemáticos. Los datos de problemas pertinentes, como la hora y la fecha de ocurrencia, los incidentes relacionados, los síntomas, los pasos de solución de problemas anteriores y la categoría de problemas ayudan al equipo de administración de problemas a investigar la causa raíz.

El tercer paso es categorizar el problema. La categorización de problemas debe coincidir con la categorización de incidentes. La categorización de incidentes [y problemas] implica asignar una categoría principal y secundaria al problema. Este paso es beneficioso de varias maneras. Un beneficio es que le permite a la mesa de servicio ordenar y modelar incidentes que ocurren con regularidad. El modelado permite la asignación automática de priorización. El tercer y más importante beneficio es la capacidad de recopilar e informar sobre los datos de la mesa de servicio.

Estos datos le permiten a la organización no solo rastrear las tendencias de los problemas, sino también evaluar su efecto en la demanda del servicio y la capacidad del proveedor del servicio.

El cuarto paso es priorizar el problema. La prioridad se asocia al nivel del impacto que puede ocasionarse tanto en los propios usuarios como en la totalidad de la empresa. Por otro lado, se ha de entender que la urgencia viene a ser tiempo en la cual se debe resolver el problema. De igual manera, el impacto mide la extensión del perjuicio ocasionado en la organización. La priorización del problema permite que una organización utilice los recursos de investigación de manera más efectiva. También

48 permite a las organizaciones mitigar los daños al acuerdo de nivel de servicio (SLA) mediante la reasignación de recursos tan pronto como se conoce el problema.

El quinto paso es un proceso de dos partes, que implica investigar y diagnosticar el problema. La velocidad a la que se investiga y diagnostica un problema depende de su prioridad asignada. Las cuestiones de alta prioridad siempre deben abordarse primero, ya que su impacto en los servicios es el mayor. La categorización correcta ayuda aquí, ya que identificar tendencias es más fácil cuando las categorías de problemas se correlacionan con las categorías de incidentes. El diagnóstico generalmente implica analizar los incidentes que conducen al informe del problema, así como otras pruebas que pueden no ser posibles a nivel de la mesa de servicio, como el análisis avanzado de registros.

El sexto paso es identificar una solución para el problema.

Siempre se debe indicar una solución, ya que los problemas no se resuelven en el nivel del incidente. Una solución alternativa permite que la mesa de servicio restaure los servicios a los usuarios mientras se resuelve el problema. Un problema puede tardar desde una hora hasta meses en resolverse, por lo tanto, una solución es vital. Un problema se considera abierto hasta que se resuelva, por lo que una solución alternativa solo debe considerarse una medida temporal.

El paso siete es levantar un registro de error conocido. Una vez que la solución ha sido identificada, debe comunicarse al personal dentro de la organización como un error conocido. Es una buena práctica registrar un error conocido en una base de conocimiento de incidentes y lo que ITIL llama una base de datos de errores conocidos (KEDB). La documentación de la solución provisional permite a la mesa de servicio resolver incidentes rápidamente y evitar que surjan más problemas en el mismo problema.

El paso ocho es resolver el problema. Los problemas deben resolverse siempre que sea posible. La resolución resuelve la causa subyacente de un conjunto de incidentes y evita que esos incidentes se repitan. Algunas resoluciones pueden requerir el

49 consejo de administración de cambios, ya que pueden afectar los niveles de servicio. Por ejemplo, un cambio de base de datos puede causar lentitud durante el período de cambio. Todos los riesgos deben evaluarse y contabilizarse antes de implementar la resolución. Documente los pasos tomados para resolver el problema en la base de conocimiento de la organización.

El noveno paso es cerrar el problema. Este paso solo debe ocurrir después de que el problema se haya planteado, categorizado, priorizado, identificado, diagnosticado y resuelto. Si bien muchas organizaciones se detienen en este paso, no es la última según ITIL.

El paso final es revisar el problema. Esto también se conoce como una revisión importante del problema. La revisión del problema principal es una actividad organizativa que evita problemas futuros. Durante la revisión, el equipo de administración de problemas evalúa la documentación del problema e identifica qué sucedió y por qué. Las lecciones aprendidas, como los cuellos de botella del proceso, lo que salió mal y lo que ayudó deben ser discutidos. Aquí es donde tener un registro de problemas completo ayudará. Un registro completo funcionará mucho mejor que intentar extraer los detalles de la memoria. Esta revisión del problema debería dar como resultado procesos mejorados, capacitación del personal o documentación más completa.

2.2.3.6. ¿Cómo encaja la gestión de problemas en ITIL?

La administración de problemas es solo un componente del ciclo de vida de la administración de servicios ITIL. Dentro de ITIL, existe en el proceso principal de operación de servicio. Como proceso, se conecta con muchas otras partes de ITIL. Debido a su relación con la mesa de servicio, se ve directamente afectada y afecta la administración de incidentes. También interactúa con la administración financiera, ya que el impacto financiero de un problema se considera durante las etapas de priorización y resolución. Interactúa con el diseño del servicio cuando se consideran problemas pasados y potenciales durante el proceso

50 de diseño de TI. Interactúa con la gestión del conocimiento cuando se registran problemas conocidos. Finalmente, interactúa con la mejora continua del servicio. Cuando la gestión de problemas es proactiva, ya que ambos tienen el objetivo de mejorar la calidad del servicio entregado a clientes internos y externos.

Este proceso es parte integral del éxito de la prestación de servicios a largo plazo y, por lo tanto, no debe ignorarse al diseñar un servicio de TI sólido, ya sea que se enfrente interna o externamente.