Los términos incidente y problema podrían parecer sinónimos, pero son distintos en el rol que desempeñan en lograr una calidad ideal del servicio. Es importante saber dónde la gestión de incidentes y la gestión de problemas interactúan entre sí y en qué se diferencian, especialmente cuándo termina un incidente y empieza un problema.

Gestión de incidentes

Un incidente es una interrupción no planeada de todo un servicio o solo un componente de uno. Miremos una situación para entenderlo mejor. Hay una reunión importante en 15 minutos y no se ha impreso el informe. Desafortunadamente, la impresora del departamento no está funcionando. Se genera rápidamente un ticket para tener una solución alternativa e imprimir el informe. Esto es un incidente.

El proceso de gestión de incidentes se trata de manejar incidentes y restaurar el servicio lo antes posible. En nuestra situación, el personal de la mesa de servicio se conecta rápidamente a la laptop a la impresora del departamento vecino para ayudar al usuario a tener listos los informes para la reunión. Por tanto, la meta de la gestión de incidentes es garantizar que se resuelva una interrupción o incidente tan pronto como sea posible con una solución alternativa o resolución.

Gestión de problemas

La gestión de problemas no se trata de restaurar servicios o resoluciones, sino de determinar y eliminar la causa. Se registra un problema en una mesa de servicio cuando hay incidentes repetitivos que tienen problemas comunes o si se presenta un incidente mayor que afecte a muchos usuarios. En nuestra situación, la única impresora en el departamento se daña y todos los usuarios en ese departamento se vieron afectados, lo que el personal de la mesa de servicio registra como un problema para encontrar la causa y la solución. Un incidente se puede cerrar cuando se da una solución alternativa, pero un problema se genera para corregir la impresora permanentemente, de forma que el problema no se vuelva a presentar.

De vuelta a nuestra situación, el problema de la impresora se llevará a RCA para encontrar una corrección permanente, y se controlará como un ticket de problema mientras que la compañía sigue con la solución alternativa. Si el equipo de gestión de problemas es incapaz de encontrar una solución, se documenta la solución alternativa y el problema se añade a KEDB. De esta forma, la gestión de problemas no solo se trata de eliminar incidentes al encontrar la causa raíz subyacente, sino que también determina la solución más viable que se pueda implementar para minimizar las interrupciones. Algunas veces, aunque se conoce la causa raíz, la solución más viable es implementar una solución alternativa y documentarla como un error conocido.

A pesar de ser distintas, la gestión de incidentes y de problemas se complementan entre sí y están cercanamente alineadas. La gestión de incidentes garantiza la continuidad en las operaciones corporativas, mientras que la gestión de problemas se ocupa de los problemas subyacentes.

Un sistema integrado de mejores prácticas de prestación de servicios mejora los servicios corporativos y las funciones de los servicios de TI. Un proceso efectivo para la gestión de problemas tiene interacción con otros procesos de ITSM.

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

Gestión de incidentes

La gestión de incidentes es el proceso metodológico de registrar, categorizar, priorizar, asignar y resolver problemas en una organización. La meta de la gestión de incidentes es restablecer los servicios interrumpidos tan pronto como sea posible; con frecuencia, esto significa que se implemente una solución alternativa en lugar de una permanente. Toda actividad en esta práctica se documenta de manera detallada y se remite al equipo de gestión de problemas, el cual inicia el RCA para desarrollar una solución permanente. Puede verse que, a pesar de que la gestión de problemas tiene su propio proceso, depende de un proceso robusto para la gestión de incidentes.

Gestión de cambios

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

De acuerdo con el marco de ITSM, la responsabilidad de la gestión de problemas concluye con el hallazgo de la causa raíz, que conlleva una solución a un problema, y de hecho la implementación de la solución se realiza con control de cambios. Ya que implementar un cambio involucra gestionar riesgos en varias unidades corporativas, se requiere un proceso como tal 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 con él.

Gestión de activos de TI

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

Las prácticas de gestión de activos y de problemas pueden cruzarse cuando los problemas emergen de activos de hardware y software que la organización usa. Cuando la causa raíz de un problema parece estar en un producto o servicio, el registro detallado de la gestión de activos de TI del inventario 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 al estudiar el impacto de un incidente, examinando los efectos de implementar una solución y dando información cuando sea necesario mediante el RCA.

Veamos esto en una situación.

Zylker es un proveedor de fotografía de stock con rápido crecimiento en la India. Un gerente en Bombay ha tenido problemas para generar informes mensuales a partir del servidor de SQL en Nueva Delhi. Se ha generado un incidente y el personal de la mesa de servicio ha notificado a los técnicos de Nueva Delhi. Como solución alternativa temporal, los informes se generan localmente y se envían para garantizar la continuidad de la compañía.

El proactivo equipo de gestión de problemas decide ejecutar un análisis de tendencias sobre incidentes que se presentaron en los últimos seis meses. Encuentran varios incidentes pertenecientes al servidor en Nueva Delhi. Esto hace que inicien un ticket de problema y procedan con el análisis investigativo usando los datos acumulados de todos los incidentes documentados.

El técnico en Nueva Delhi ve que el servidor de SQL usa varios tipos de protocolos, incluyendo iSCSI y Fiber Channel, para vincular instalaciones de almacenamiento de datos. Ya que ambos protocolos funcionan en una red de Ethernet, hay dudas sobre si el switch de bloque local se configuró para la transferencia de grandes paquetes de datos. El técnico recibe datos del equipo de gestión de activos de TI y verifica que el switch no era la causa. Esto tiene respaldo en la evidencia de que generar informes localmente no era un problema.

La red de área amplia (WAN) es la siguiente en el análisis, ya que un gerente desde Bombay está teniendo problemas para generar el informe mensual. El técnico, debido a su experiencia en problemas de red, tiene dudas sobre el flujo del tráfico al final de cada mes, de forma que instala un software en los routers y switches de la compañía para analizar el tráfico que pasa por ellos y agrega estadísticamente la información.

El software genera gráficos y diagramas que indican los protocolos principales que se usaron, junto con el ancho de banda que cada protocolo consumió en un mes. Esto muestra un uso significativo del ancho de banda al final del mes alrededor del mismo momento en que se genera el informe mensual. Tras un examen cuidadoso, se revela que se programaron respaldos completos alrededor del mismo momento que el informe mensual, y esto causó un cuellos de botella importante en la WAN.

Ahora que se identifica la causa raíz del problema, el técnico genera un ticket de cambio para reprogramar el respaldo de imagen a las primeras horas de la mañana antes de que inicien labores, aprovechando el tráfico en la red.

He aquí un resumen general de los pasos que se dieron en esta situación:

Todas las prácticas de ITSM tienen una intrincada relación con otras prácticas de TI. Cuando su gestión de problemas madure 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 sana y orientada a la compañía.